mjs at apple.com
Wed May 13 19:05:19 PDT 2009
Responding to both of you...
On May 13, 2009, at 12:13 PM, Rob Kroeger wrote:
> 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>
>> On May 13, 2009, at 12:18 AM, Meryl Silverburgh wrote:
>> Does webkit cache squirrelfish bytecode? For example, multiple can
>> different pages for the same domain).
>> When webkit parses the JS file and builds squirrelfish-bytecode,
>> 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
>> 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
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
> definitions) occupies a large portion of the application startup time.
> Somehow speeding this up (caching the parsed and compiled version of
> 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
More information about the webkit-dev