Community
Participate
Working Groups
Build Identifier: 1.4.0 usecase : A Composite with 30 Labels, 15 TextFields and 15 Combos. Each Combo get a list of 25 items. The load of this Composite take many seconds under IE8 under Firefox 5 is instantaneous. memory use is also very high : The memory footprint is also extremly high so that the performance are probably worst after the real application load many Composites with Combo (I didn't mess that). After loading 27 Composites with 225 Labels, 108 Combos, 117 TextFields and 9 Tables then the memory overhead under IE8 was 260 MB. This number of components are for us real application a usual use case.A solution should be a lazy loading of the graphical items for IE even if the list of item comes with a little delay. Reproducible: Always
Created attachment 199974 [details] View to reproduce the problem The view contains Tab Folder. The contents of the TabItems are created by the first click on it. In the bottom the checkbox "Combo" defines if the created Composite contains Combos or not. If not (unchecked) the Combos are replaced with TextFields.
Are you using the default RAP theme? Is switching to "classic" theme improve the performance? I don't think that a consumption of 260 MB in IE for 500+ widgets is so high. Please note that Firefox 5/IE9 are using GPU hardware acceleration (if enabled).
(In reply to comment #2) > Are you using the default RAP theme? Is switching to "classic" theme improve > the performance? I don't think that a consumption of 260 MB in IE for 500+ > widgets is so high. Please note that Firefox 5/IE9 are using GPU hardware > acceleration (if enabled). The application must also run on IE7 and IE8. I use the rap theme and switching to classic doesn't help. I guess that the memory comsumption influences the performance because after loading the 500+ widget the performances are worse. Do you know how to measure the real used memory inside an IE process ?
(In reply to comment #3) > Do you know how to measure the real used memory inside an IE process ? I'm using Microsoft (Sysinternals) Process Explorer. The actual memory consumption is Physical Memory -> Working Set -> WS Private.
Created attachment 202072 [details] Prformance report by Serge Démoulin Serge made a RAP Custom Widget "LightCombo" based on "HTML select" that acts as Combo and is it "as light as possible". After that he did compare the performances between the standard RWT Combo and this LightCombo.
Created attachment 205008 [details] Implementation of a light combo This zip-file contains 2 eclipse projects : rap.widget.lightcombo : Custom RAP Widget rap.widget.lightcombo.test : RAP Application to test it The documentation is in german.
The bad performance with many elements (the list-items) having the same parent is typical for IE. Howerver, the itmes are actually not created in DOM until the comobo is opend. That leaves only the actual widgets-object which BasicList#setItems creates. If it turns out that this is the problem, nothing short of a complete re-implementation of BasicList (and adapting all widgets that use it) would solve the issue. (Another way would to set the items lazily in Combo.js, but since they would be created on selection the initial item, the is probably not much to win.)
With commit 962a4d343b4a03f73a49801bb401a853b1e74c7c list items are created on demand. This improves the performance of pages with many Combo with a lot items. List items are created when Combo operation requires them - selection, show list, mouse wheel scroll...
Does this fix affect IE only? Or does this affect all browsers? I wasn't looking too deeply into the commit but from what I saw I got the impression that it changes the behaviour in all browsers, doesn't it?
(In reply to Markus Knauer from comment #9) > Does this fix affect IE only? Or does this affect all browsers? I wasn't > looking too deeply into the commit but from what I saw I got the impression > that it changes the behaviour in all browsers, doesn't it? Yes... This fix affects all browsers.
> A solution should be a lazy loading of the graphical items for IE even if the list of item comes with a little delay. Mark as fixed.
