LGTM
http://gwt-code-reviews.appspot.com/89810/diff/4001/4006
File dev/core/src/com/google/gwt/dev/js/EvalFunctionsAtTopScope.java
(right):
http://gwt-code-reviews.appspot.com/89810/diff/4001/4006#newcode74
Line 74:
Extra whitespace in this file.
LGTM, but with a few small changes requested. No need for rereview.
http://gwt-code-reviews.appspot.com/89810/diff/1/2
File dev/core/src/com/google/gwt/dev/jjs/impl/FragmentExtractor.java
(right):
http://gwt-code-reviews.appspot.com/89810/diff/1/2#newcode175
Line 175: * the call to
I can review it. -Lex
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
This patch demonstrates the idea and some of the dispatch semantics
that need to be accounted for. It stringifies individual functions,
which is much too fine-grained for anything that could be deployed.
It seems to me that optimally stringifying a GWT module and performing
runAsync splitting is
This is neat, Bob! It's also timely. I've been looking into
prefetching for runAsync code, and the folks I've talked to are
worried about locking up the browser with giant evals. Lazy eval as
in this patch would enable people to prefetch code more aggressively.
Like you say, it likely needs
Lex or Bob, would one of you mind taking this? I'm kind of heads down in
hosted mode.
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Plus, if we ultimately make changes to the compiler along the lines of not
eagerly making calls static, this patch here will be critical to making that
cheap.
On Sat, Oct 31, 2009 at 1:51 AM, Ray Cromwell cromwell...@gmail.com wrote:
I ran tests on iPhone and Android 2.0 SDK with Showcase and
Very cool find.
On Fri, Oct 30, 2009 at 8:00 PM, cromwell...@gmail.com wrote:
Note, that if you don't desire correct stack traces, you can use the
following construct:
_.foo = function() { ... }
This results in a 6% post-gzip size reduction on Showcase. It might be
useful to introduce a
On Fri, Oct 30, 2009 at 8:24 PM, Bruce Johnson br...@google.com wrote:
In terms of design, I think this would actually be best as a
permutation-specific conditional deferred binding property that the compiler
is sensitive to (that was a mouthful), so that it would be possible to let
app
I wish we could wrap that all up in a simpler-to-understand package.
But a good article would make it at least bearable.
On Saturday, October 31, 2009, Ray Cromwell cromwell...@gmail.com wrote:
On Fri, Oct 30, 2009 at 8:24 PM, Bruce Johnson br...@google.com wrote:
In terms of design, I
Maybe it would make sense to move properties which the compiler relies on
into a special CompilerFlags.gwt.xml module, then if you want to change
class meta data, class cast checking, aggressive optimization, or stack
info, there'd be one centralized place to look at and document all the
flags.?
yep, and all of them should be per-perm
On Saturday, October 31, 2009, Ray Cromwell cromwell...@gmail.com wrote:
Maybe it would make sense to move properties which the compiler relies on
into a special CompilerFlags.gwt.xml module, then if you want to change class
meta data, class cast
I ran tests on iPhone and Android 2.0 SDK with Showcase and I didn't see any
significant different in startup times over wifi (3g/3dge may be a different
story), so the latency improvement really only shows up in degenerate test
cases where all functions are polymorphic, small and/or empty, so
13 matches
Mail list logo
