Responding to both of you...
On May 13, 2009, at 12:13 PM, Rob Kroeger wrote:
Hi,
On Wednesday, May 13, 2009, Jeremy Orlow <[email protected]> wrote:
On Wed, May 13, 2009 at 1:11 AM, Maciej Stachowiak <[email protected]>
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
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
