[webkit-dev] squirrelfish-bytecode

[Maciej Stachowiak]

Responding to both of you...

On May 13, 2009, at 12:13 PM, Rob Kroeger wrote:

> Hi,
>
> On Wednesday, May 13, 2009, Jeremy Orlow <jorlow at chromium.org> wrote:
>> On Wed, May 13, 2009 at 1:11 AM, Maciej Stachowiak <mjs at apple.com>  
>> wrote:
>>
>>
>> On May 13, 2009, at 12:18 AM, Meryl Silverburgh wrote:
>>
>>
>> Hi,
>>
>> Does webkit cache squirrelfish bytecode? For example, multiple can  
>> use
>> the same javascript file (e.g. common javascript libraries, like
>> jquery, or same domain uses some common javascript file across
>> different pages for the same domain).
>>
>> When webkit parses the JS file and builds squirrelfish-bytecode,   
>> does
>> it cache it ? so that subsequence loading of the same js file will
>> skip the js compile process?
>>
>>
>>
>> We don't currently cache the bytecode (or the native code). It is  
>> an option we have considered, however, currently, code generation  
>> is a trivial portion of JS execution time (< 2%), so we're not  
>> pursuing this at the moment.
>>
>>
>> What does the < 2% number reflect?  The percent of time while  
>> running a particular benchmark or something?

A wide variety of benchmarks, and also looking at profiles of real  
page loads (where JS processing time is only a fraction of the total  
load time).

>> I totally believe that the speed of runtime is not really affected  
>> by it, but what about page load latency?  Compile time is a non- 
>> trivial component of load time for most JIT compilers I've heard of.

Page load speed is very important to us. Right now, based on profiles,  
it looks to us like we can improve page load speed more by speeding up  
JS execution, than by caching bytecode. This is true even for pages  
loading fairly hefty chunks of JavaScript. We'd be glad to do  
profiling of specific example pages if you have any in mind.


> [Speaking from the point of view of my day job working on Mobile Gmail
> instead of occasional evening webkit hacker]
>
> Performance tests on mobile gmail for iPhone show that the time from
> loading the first few bytes of the page from AppCache to the
> completion of executing the "static" JavaScript (function and variable
> definitions) occupies a large portion of the application startup time.
> Somehow speeding this up (caching the parsed and compiled version of
> JavaScript stored in AppCache maybe?) would be a huge benefit to
> complex web applications.

 From that information, I would guess much of the cost is actually  
executing the global code, though JS parsing may also be a factor. I  
would also expect significant improvements in iPhone 3.0 and beyond to  
JS execution speed.

That being said, if we find scenarios where parsing is a bottleneck,  
we'll look into the possibility of caching bytecode or native code. It  
was one of our original ideas for bytecode, and the only reason we  
haven't done it is that we haven't yet found evidence that it would  
help.

Regards,
Maciej