Bug 26513 - Improve performance of Lexer by allocating big inline buffer
Summary: Improve performance of Lexer by allocating big inline buffer
Status: RESOLVED LATER
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Other All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-18 07:40 PDT by Adam Treat
Modified: 2012-10-24 12:58 PDT (History)
5 users (show)

See Also:


Attachments
big inline buffers (2.60 KB, patch)
2009-06-18 09:50 PDT, Adam Treat
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Treat 2009-06-18 07:40:04 PDT
Currently the JavaScriptCore Lexer allocates two buffers for storing the source to be parsed.  When the lexer is cleared the buffers are swapped out with new buffers.  This change allocates a big inline buffer during object creation so that the swap is only necessary if the size exceeds 512.
Comment 1 Adam Treat 2009-06-18 09:50:14 PDT
Created attachment 31500 [details]
big inline buffers

The patch is from Yong Li.  I've tried testing it on Sunspider, but I'm getting inconsistent results with ToT QtWebKit.  I don't even know if Sunspider would be relevant for this change, but perhaps someone else can look at it...
Comment 2 Maciej Stachowiak 2009-06-18 10:33:25 PDT
Comment on attachment 31500 [details]
big inline buffers

Looks good, but we need some solid perf results.
Comment 3 George Staikos 2009-06-18 10:52:14 PDT
I believe we only have performance info on mobile.  Should be easy to test it on a desktop build though.
Comment 4 Sam Weinig 2009-06-21 13:33:44 PDT
Is any perf info available yet?  It is hard to review this without a concrete understanding of the performance benefit.
Comment 5 Adam Treat 2009-06-22 08:22:28 PDT
Removing from the review queue for now as I've been unsuccessful in trying to measure a performance impact of this patch.  The plan is to try and find such a performance impact on embedded hardware where the patch originated.  Once we find such an impact, we'll revisit.
Comment 6 George Staikos 2009-07-17 09:24:51 PDT
Not CE specific.
Comment 7 Eric Seidel (no email) 2012-10-24 12:43:24 PDT
Sill an issue?
Comment 8 Yong Li 2012-10-24 12:58:48 PDT
(In reply to comment #7)
> Sill an issue?

shouldn't be a big issue now. I was using a very slow memory allocator in that days.