Bug 16738 - Collector block offset could be stored as an cell offset instead of a byte offset
Summary: Collector block offset could be stored as an cell offset instead of a byte of...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-04 23:23 PST by Henry Mason
Modified: 2008-01-05 00:26 PST (History)
0 users

See Also:


Attachments
Cell offset usage (2.49 KB, patch)
2008-01-04 23:27 PST, Henry Mason
mjs: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Henry Mason 2008-01-04 23:23:26 PST
Contrary to comments in the code to the contrary, storing the "next" field as a byte offset rather than a cell offset seems to be hurting performance. Both shark and timing tests with SunSpider show a small performance gain by switching to cell offsets. As an added bonus, using cell offsets eliminates a lot of somewhat ugly casting.
Comment 1 Henry Mason 2008-01-04 23:27:15 PST
Created attachment 18284 [details]
Cell offset usage
Comment 2 Maciej Stachowiak 2008-01-04 23:28:16 PST
Comment on attachment 18284 [details]
Cell offset usage

r=me
Comment 3 Maciej Stachowiak 2008-01-04 23:36:04 PST
Henry requests that anyone landing this patch should verify that it is a speedup since it is a little mysterious why.
Comment 4 Mark Rowe (bdash) 2008-01-05 00:26:28 PST
Landed in r29195.  My testing showed this was a 0.4% speedup.