Bug 338647

Comment 1 Tim Buschtoens 2011-03-02 05:59:10 EST

Suggestion: Reducing code for specific applications:

Parsing/executing the javascript-classes needs about 1 second per 100kb code on the ipod. We currently have ~890 KB code. For lightweight applications that only use the simplest widgets one can remove 300 KB code max, gaining around 3 seconds. Currently this has to be done completely manual in QooxdooResourceUtil. A more comfortable method would be desirable.

Comment 2 Tim Buschtoens 2011-03-02 06:11:47 EST

Created attachment 190129 [details]
dispatch initial request early

Suggestion: Dispatch initial request early

Its possible to dispatch the initial request before all classes have been parsed, but this only saves the time needed for the actual turnaround, which depends more an the netweork and server than the client. The attached patch works, but has some quirks that need some refactoring.

A cheaper variant it to only ommit the timer on the initial request (sendImmediate instead of send), though that only gets as a bit more than 60ms.

Comment 3 Tim Buschtoens 2011-03-02 06:24:54 EST

Created attachment 190130 [details]
initialize classes lazily

Suggestions: Initialize javascript classes lazily

Some tasks while defining a class can wait until an actual instance is created. This saves around 1.5 seconds on the iPod. There is no real downside besides it beeing a very sensitive area to change something. The patch works fine (needs some cleaning up), except that it uses a workaround that initializes specific classes (4) at once because their prototype is accessed before an instance is created.

Comment 4 Tim Buschtoens 2011-03-02 06:37:25 EST

Further ideas:

- Initializing the property-setter/getter needs a lot of time due to it using eval. (Its already done lazily.) It could be replaced using "normal" functions (using ifs and clousures). Problem is a) its a lot for work, b) its a sensitive area and c) the setter/getter would be less optimized. To check if the subsequent calls would be segnificantly slower some dummy tests would have to be done beforehand.

- Functions "Meta#_applyTheme" und "ThemeStore#defineValues" need some considerable time, perhaps some of their tasks can be optimized or done lazily.

Comment 5 Tim Buschtoens 2011-03-02 06:56:52 EST

The time needed by "Meta#_applyTheme" is used partly be property initialization and partly by parsing the BordersBase. We should see if BordersBase can be reduced (unused borders).

Comment 6 Tim Buschtoens 2011-03-02 07:06:57 EST

Most of the time of "defineValues" is used to resolve borders, gradients and fonts. This could be done lazily in ThemeValues, how much time would be saved would depend on how many of these values are used initially.

Comment 7 Tim Buschtoens 2011-04-05 06:30:16 EDT

Created a separate bug for refactoring ThemeStore.

Comment 8 Tim Buschtoens 2011-04-05 11:00:33 EDT

Comitted the "initialize classes lazily" patch to CVS HEAD with some changes. The aforementioned issue with some classes accessing their prototype early is solved by calling __initializeClass explicitly in such cases.

Comment 9 Tim Buschtoens 2011-04-06 12:39:45 EDT

Otimizations for "Meta#_applyTheme" commited to CVS HEAD.

Instead of parsing BordersBase while initializing, the borders are now generated lazily. To achieve this, BordersBase was refactored and renamed to BorderDefinitions and is now a static class . Since these borders are also almost the only ones using named colors, we took the opportunity and made some minor changes to the color-management, which now ommits the ColorTheme and works entirely within ThemeStore.

Comment 10 Tim Buschtoens 2011-04-07 06:19:07 EDT

(In reply to comment #2)
> A cheaper variant it to only ommit the timer on the initial request
> (sendImmediate instead of send), though that only gets as a bit more than 60ms.

Commited this to CVS HEAD. 60ms are not much, but they are basically free.

Comment 11 Ivan Furnadjiev 2013-01-14 06:27:08 EST

As all subtask are fixed I will close this as fixed too.