Community
Participate
Working Groups
While current desktop-systems are fast enough to load a RAP-application without any considerable delay, mobile platforms such as the iPhone are somewhat slower. We should try finding ways to improve startup time for such devices. Some research has been done, mostly using a 2nd gen iPod touch that currently needs 16-18 seconds to load a rap application (non-debug variant, second application start). An iPhone 4 only needs around 8 seconds. More in the comments. Also see Bug 332900 - [Client] Streamline startup process, which is complementary to anything suggested here.
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.
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.
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.
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.
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).
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.
Created a separate bug for refactoring ThemeStore.
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.
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.
(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.
As all subtask are fixed I will close this as fixed too.