[gwt-contrib] Re: Automatic Split Point Creation and JS Stack Emulation
Ok, after digging more into CodeSplitter and AsyncFragmentLoader classes, I can say now that it is simply not possible (under the control of Lex obviously). CodeSplitter relies on CFA (Control Flow Analyzer) to extract the dependencies. If the user code is not natively modular (Spaghetti code), the compiler will flag every types as "shared" and let the code go into the leftovers fragments (or the initial one). We would end up with a big (huge?) fragment with no real way to find out automagically the ideal split points . As Lex would say "It's simply devilish to come up with a precise splitting algorithm that does so" Too bad :-) Sami On Thu, Oct 1, 2009 at 5:43 PM, Ian Petersen wrote: > > On Thu, Oct 1, 2009 at 8:18 AM, Sami Jaber wrote: > > Yes you are right, but do you really think that in the case of a failure, > > you would try to change your code flow differently depending on where you > > are ? Except displaying a generic message, you won't be able to go > further > > as I understand the mechanism. > > Concerning the second point, this is the crucial question. There are a > few > > scenarios that could be conceivable. > > We can imagine that a permuation of 1 Mo could be splitted into 2 chunks > of > > 500 Ko or 4 chunks of 250 Ko of 10 chunks of 5 Ko, that is what I call a > > "balanced tree" or "balanced split points". Most people would probably > want > > to split their permutations only to get responsiveness and decrease > startup > > time without digging more in the code flow... > > But if you say that it is not possible at all, I believe you ... > > I'm not sure that it's not possible, I think it's more that doing it > under automatic control is undesirable. A split point will, on first > execution, introduce a delay in processing. Such delays can be > acceptable if the programmer can control where they go. If the > compiler introduces a delay at an apparently random place in the code, > the delay could very well be disruptive. Forcing the programmer to > choose when to allow delays and when not leaves the control in the > programmer's hands, and prevents automatically-generated catastrophes. > > Ian > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Automatic Split Point Creation and JS Stack Emulation
On Thu, Oct 1, 2009 at 8:18 AM, Sami Jaber wrote: > Yes you are right, but do you really think that in the case of a failure, > you would try to change your code flow differently depending on where you > are ? Except displaying a generic message, you won't be able to go further > as I understand the mechanism. > Concerning the second point, this is the crucial question. There are a few > scenarios that could be conceivable. > We can imagine that a permuation of 1 Mo could be splitted into 2 chunks of > 500 Ko or 4 chunks of 250 Ko of 10 chunks of 5 Ko, that is what I call a > "balanced tree" or "balanced split points". Most people would probably want > to split their permutations only to get responsiveness and decrease startup > time without digging more in the code flow... > But if you say that it is not possible at all, I believe you ... I'm not sure that it's not possible, I think it's more that doing it under automatic control is undesirable. A split point will, on first execution, introduce a delay in processing. Such delays can be acceptable if the programmer can control where they go. If the compiler introduces a delay at an apparently random place in the code, the delay could very well be disruptive. Forcing the programmer to choose when to allow delays and when not leaves the control in the programmer's hands, and prevents automatically-generated catastrophes. Ian --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Automatic Split Point Creation and JS Stack Emulation
Yes you are right, but do you really think that in the case of a failure,
you would try to change your code flow differently depending on where you
are ? Except displaying a generic message, you won't be able to go further
as I understand the mechanism.
Concerning the second point, this is the crucial question. There are a few
scenarios that could be conceivable.
We can imagine that a permuation of 1 Mo could be splitted into 2 chunks of
500 Ko or 4 chunks of 250 Ko of 10 chunks of 5 Ko, that is what I call a
"balanced tree" or "balanced split points". Most people would probably want
to split their permutations only to get responsiveness and decrease startup
time without digging more in the code flow...
But if you say that it is not possible at all, I believe you ...
Sami
On Thu, Oct 1, 2009 at 4:56 PM, John Tamplin wrote:
> On Thu, Oct 1, 2009 at 10:39 AM, Sami Jaber wrote:
>
>> In fact, I meant keeping the actual code as a normal developer would have
>> to write manually.
>> Most of them will likely provide a kind of generic Async implementation.
>> If one is able to find the right split point, all the call sites would be
>> rewritten with a :
>> GWT.runAsync() {success();failure();}. The error handling would be defined
>> with a custom method or impl provided by the developer..
>> The idea is to get rid of all the boiler plate code required by
>> codesplitting, specially all the soyc report analysis steps that many dev
>> will (unfortunately) give up...
>> I'm sure that I miss something, but this is the "something" that I would
>> want to know :-)
>>
>
> How can the developer provide the failure handling code if that point can
> be made anywhere at the compiler's discretion? How can the compiler know
> where is a good point to split the program from a user's perspective?
>
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> >
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Automatic Split Point Creation and JS Stack Emulation
On Thu, Oct 1, 2009 at 10:39 AM, Sami Jaber wrote:
> In fact, I meant keeping the actual code as a normal developer would have
> to write manually.
> Most of them will likely provide a kind of generic Async implementation. If
> one is able to find the right split point, all the call sites would be
> rewritten with a :
> GWT.runAsync() {success();failure();}. The error handling would be defined
> with a custom method or impl provided by the developer..
> The idea is to get rid of all the boiler plate code required by
> codesplitting, specially all the soyc report analysis steps that many dev
> will (unfortunately) give up...
> I'm sure that I miss something, but this is the "something" that I would
> want to know :-)
>
How can the developer provide the failure handling code if that point can be
made anywhere at the compiler's discretion? How can the compiler know where
is a good point to split the program from a user's perspective?
--
John A. Tamplin
Software Engineer (GWT), Google
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Automatic Split Point Creation and JS Stack Emulation
In fact, I meant keeping the actual code as a normal developer would have to
write manually.
Most of them will likely provide a kind of generic Async implementation. If
one is able to find the right split point, all the call sites would be
rewritten with a :
GWT.runAsync() {success();failure();}. The error handling would be defined
with a custom method or impl provided by the developer..
The idea is to get rid of all the boiler plate code required by
codesplitting, specially all the soyc report analysis steps that many dev
will (unfortunately) give up...
I'm sure that I miss something, but this is the "something" that I would
want to know :-)
Sami
On Thu, Oct 1, 2009 at 3:45 PM, John Tamplin wrote:
> On Thu, Oct 1, 2009 at 9:24 AM, Sami Jaber wrote:
>
>> I was wondering why wouldn't it be possible to automatically create the
>> split point based on the information provided by the AST and Compilation
>> Analysis
>> We know precisely where the code cost JS size and where are the call sites
>> for a given split point. Why not hooking up the AST to create a balanced
>> tree and thus create several small sized fragment ?
>> Those generated split points would be adapted regarding the code evolution
>> and the user would never care of this hidden functionality
>>
>
> If you mean transparently changing a synchronous call into an asynchronous
> call, there are a couple of insurmountable (IMHO) problems:
>
>- you can't return back to the event loop or you lose the call stack,
>which means the browser is totally locked (except on Chrome) until the
> fetch
>returns. On most browsers, timers won't fire during a busy-wait poll and
>you will also get slow script warnings
>- async calls can fail, and you have no way of handling the errors in a
>useful way. Even if you throw an exception, the programmer has to be
>prepared for every call to fail, which in practice means only catching the
>exception at a high level and aborting
>
> I think it is far better to have the programmer explicitly specify the
> split point so they know that it is in fact an async call, can usefully
> handle error conditions at that point, and allows the browser to run its
> event loop.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> >
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Automatic Split Point Creation and JS Stack Emulation
On Thu, Oct 1, 2009 at 9:24 AM, Sami Jaber wrote: > I was wondering why wouldn't it be possible to automatically create the > split point based on the information provided by the AST and Compilation > Analysis > We know precisely where the code cost JS size and where are the call sites > for a given split point. Why not hooking up the AST to create a balanced > tree and thus create several small sized fragment ? > Those generated split points would be adapted regarding the code evolution > and the user would never care of this hidden functionality > If you mean transparently changing a synchronous call into an asynchronous call, there are a couple of insurmountable (IMHO) problems: - you can't return back to the event loop or you lose the call stack, which means the browser is totally locked (except on Chrome) until the fetch returns. On most browsers, timers won't fire during a busy-wait poll and you will also get slow script warnings - async calls can fail, and you have no way of handling the errors in a useful way. Even if you throw an exception, the programmer has to be prepared for every call to fail, which in practice means only catching the exception at a high level and aborting I think it is far better to have the programmer explicitly specify the split point so they know that it is in fact an async call, can usefully handle error conditions at that point, and allows the browser to run its event loop. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
