Comment #3 on issue 3016 by [email protected]: Rewrite the V8 parser
http://code.google.com/p/v8/issues/detail?id=3016
As for the compiler, we do lazy compile where-ever we can. The parser only
creates a shared function info with the source offsets so that when we
actually run the function, it's compiled from the function definition at
the source offset.
The unoptimized code is not produced in a separate thread, and the gains
would be rather small since it works quite fast. Since it's done lazily, it
will block execution either way. The optimized code is already being
compiled in a second thread in the most cases (excluding OSR), only code
generation happens on the main thread.
We do have a script to code cache. I'm not 100% sure about this, but at
least top-level javascript code is cached, so as long as the embedder
(chrome) tells us to create code from the same (external) string, we should
be just fetching it from the cache. I don't remember the details about that
anymore though, but it probably covers part of your Google Search example.
We could cache the abstract syntax tree, but given that we might also not
use the AST format in the optimzing compiler altogether in the long-term
future, I'm not sure work in this area is a good investment.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
