Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 338647 - [Client] Improve startup time
Summary: [Client] Improve startup time
Status: RESOLVED FIXED
Alias: None
Product: RAP
Classification: RT
Component: RWT (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: 1.5   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 321213 327453 338412 341884
Blocks: 323031
  Show dependency tree
 
Reported: 2011-03-02 05:56 EST by Tim Buschtoens CLA
Modified: 2013-01-14 06:27 EST (History)
1 user (show)

See Also:


Attachments
dispatch initial request early (9.80 KB, patch)
2011-03-02 06:11 EST, Tim Buschtoens CLA
no flags Details | Diff
initialize classes lazily (11.33 KB, patch)
2011-03-02 06:24 EST, Tim Buschtoens CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Buschtoens CLA 2011-03-02 05:56:19 EST
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.
Comment 1 Tim Buschtoens CLA 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 CLA 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 CLA 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 CLA 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 CLA 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 CLA 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 CLA 2011-04-05 06:30:16 EDT
Created a separate bug for refactoring ThemeStore.
Comment 8 Tim Buschtoens CLA 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 CLA 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 CLA 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 CLA 2013-01-14 06:27:08 EST
As all subtask are fixed I will close this as fixed too.