Vaadin 7 and 6 IE8 performance comparison

Just see render logs from browser:

Vaadin 7

INFO: Making UIDL Request with params: 30ae1a56-3f76-4441-b30d-cb5f2217bc1b[["269","com.vaadin.shared.ui.button.ButtonServerRpc","click",[{"clientX":"260", "metaKey":false, "clientY":"174", "relativeX":"41", "relativeY":"18", "shiftKey":false, "altKey":false, "ctrlKey":false, "type":"1", "button":"LEFT"}]
]]
  Thu Oct 10 14:13:52 GMT+300 2013 com.vaadin.client.VConsole
INFO: Server visit took 1297ms
  Thu Oct 10 14:13:52 GMT+300 2013 com.vaadin.client.VConsole
INFO: JSON parsing took 0ms
  Thu Oct 10 14:13:52 GMT+300 2013 com.vaadin.client.VConsole
INFO: Handling message from server
  Thu Oct 10 14:13:52 GMT+300 2013 com.vaadin.client.VConsole
INFO:  * Handling resources from server
  Thu Oct 10 14:13:52 GMT+300 2013 com.vaadin.client.VConsole
INFO:  * Handling type inheritance map from server
  Thu Oct 10 14:13:52 GMT+300 2013 com.vaadin.client.VConsole
INFO: Handling type mappings from server
  Thu Oct 10 14:13:52 GMT+300 2013 com.vaadin.client.VConsole
INFO: Handling resource dependencies
  Thu Oct 10 14:13:52 GMT+300 2013 com.vaadin.client.VConsole
INFO:  * Handling type mappings from server completed: 15 ms
  Thu Oct 10 14:13:52 GMT+300 2013 com.vaadin.client.VConsole
INFO:  * Handling meta information
  Thu Oct 10 14:13:52 GMT+300 2013 com.vaadin.client.VConsole
INFO:  * Creating connectors (if needed)
  Thu Oct 10 14:13:52 GMT+300 2013 com.vaadin.client.VConsole
INFO:  * Updating connector states
  Thu Oct 10 14:13:52 GMT+300 2013 com.vaadin.client.VConsole
INFO:  * Handling locales
  Thu Oct 10 14:13:52 GMT+300 2013 com.vaadin.client.VConsole
INFO:  * Updating connector hierarchy
  Thu Oct 10 14:13:52 GMT+300 2013 com.vaadin.client.VConsole
INFO:  * Sending hierarchy change events
  Thu Oct 10 14:13:52 GMT+300 2013 com.vaadin.client.VConsole
INFO:  * Running @DelegateToWidget
  Thu Oct 10 14:13:52 GMT+300 2013 com.vaadin.client.VConsole
INFO:  * Sending state change events
  Thu Oct 10 14:13:53 GMT+300 2013 com.vaadin.client.VConsole
INFO:  * Passing UIDL to Vaadin 6 style connectors
  Thu Oct 10 14:13:59 GMT+300 2013 com.vaadin.client.VConsole
INFO:  * Performing server to client RPC calls
  Thu Oct 10 14:13:59 GMT+300 2013 com.vaadin.client.VConsole
INFO: * Unregistered 0 connectors
  Thu Oct 10 14:13:59 GMT+300 2013 com.vaadin.client.VConsole
INFO: handleUIDLMessage: 6750 ms
  Thu Oct 10 14:13:59 GMT+300 2013 com.vaadin.client.VConsole
INFO: Starting layout phase
  Thu Oct 10 14:13:59 GMT+300 2013 com.vaadin.client.VConsole
INFO: Measured 58 non connector elements
  Thu Oct 10 14:14:04 GMT+300 2013 com.vaadin.client.VConsole
INFO: Pass 1 measured 153 elements, fired 48 listeners and did 12 layouts.
  Thu Oct 10 14:14:04 GMT+300 2013 com.vaadin.client.VConsole
INFO: Pass 2 measured 36 elements, fired 7 listeners and did 3 layouts.
  Thu Oct 10 14:14:05 GMT+300 2013 com.vaadin.client.VConsole
INFO: Pass 3 measured 11 elements, fired 5 listeners and did 3 layouts.
  Thu Oct 10 14:14:06 GMT+300 2013 com.vaadin.client.VConsole
INFO: Pass 4 measured 7 elements, fired 3 listeners and did 2 layouts.
  Thu Oct 10 14:14:06 GMT+300 2013 com.vaadin.client.VConsole
INFO: Pass 5 measured 6 elements, fired 1 listeners and did 1 layouts.
  Thu Oct 10 14:14:07 GMT+300 2013 com.vaadin.client.VConsole
INFO: No more changes in pass 6
  Thu Oct 10 14:14:07 GMT+300 2013 com.vaadin.client.VConsole
INFO: Total layout phase time: 7969ms
  Thu Oct 10 14:14:07 GMT+300 2013 com.vaadin.client.VConsole
INFO:  * Dumping state changes to the console
  Thu Oct 10 14:14:07 GMT+300 2013 com.vaadin.client.VConsole
INFO:  Processing time was 15359ms for 17848 characters of JSON

Vaadin 6

INFO: Variable burst to be sent to server:
INFO:     PID537 (class com.vaadin.terminal.gwt.client.ui.VButton) :
INFO:         state (b) : true
INFO:         mousedetails (s) : 0,328,174,false,false,false,false,1,68,16
INFO: Making UIDL Request with params: 7cc33692-2552-48ab-b7bb-812f4be9b74ctruePID537stateb0,328,174,false,false,false,false,1,68,16PID537mousedetailss
INFO: Server visit took 626ms
INFO: JSON parsing took 1ms
INFO: 228px:228:228
INFO: updateFromUIDL: 27,[object Object]

INFO: updateFromUIDL: 15,[object Object]

INFO:  Processing time was 1313ms for 15028 characters of JSON
INFO: Referenced paintables: 115

It is the epic fail.
Time to open screen changed from 1313ms to 7969ms.

How to optimize it?
I have tried to build optimized widget set - no effect. I have tried to build monolithic widgetset - no effect.

Screen from example:

http://itmages.ru/image/view/1262158/0d66bf2e

Are you running in production mode (inside web.xml)? If not VAADIN 7 tries to compile you scss every time you run you app (if he can’t find a valid styles.css in your theme folder).

However this behaviuor should occur in every browser (more or less).

I use only compiled styles in my application. I have no scss files in my theme folder or in classpath.

I assume you are using the latest 7.1.x builds.

Two things seem to be taking a significant amount of time: updating legacy components on the client side based on UIDL messages (many of the built-in components in the framework are still hybrids, using both old and new mechanisms, and will be migrated little by little to new mechanisms only) and going through multiple layout passes.

For the former, I find such a big difference strange as not that much has changed in that part for most components - in fact, some of the work that used to be done there has moved to other steps. More detailed profiling would probably be needed to find where exactly the time is spent, if e.g. some specific components are responsible for the big slow-down in your application.

For the latter, it seems your layouts are organized so that recalculating the size of one forces the recalculation of another and then another etc. in a way that require parts of the layout to be done again, going through several rounds of layouts affecting each other back and forth. Five passes is a lot in my opinion, you could test to see if e.g. fixing the size of one of the intermediate level layouts (the form?) or other component containers significantly reduces the number of passes and time needed. That could give a starting point for digging deeper.

We are using Vaadin 7.1.5 (Vaadin 7 from 7.0.0 version).

On the problem screen used GridLayout for editor form, 2 splitpanels, 2 tabsheets, 2 trees on left side. In our application we have complex layouts, and for 3 years with Vaadin 6 we had had normal performance in old IE browsers.
Also we have performance problems with Table and TreeTable.

In ie9, chrome and firefox we have well performance with Vaadin 7, but IE8 is needed for big corporate clients with Windows XP workstations.

The same here. No problem with IE 9/10, Chrome or FF but with IE8 performance are bad and we increase our response time from less than 1 sec to more than 3 sec.

During our exploring, it seems that “handleUIDLMessage” phase is one of the most expensive.

As Yuriy, we’ve tried to build optimized widget set and monolithic widgetset with no effects.

See our console logs during a tabsheet switch :

  Mon Oct 14 13:25:44 GMT+200 2013 com.vaadin.client.VConsole
INFO: Making UIDL Request with params: eed7e8e6-b4f2-44b7-88ef-b3d6e7fd1f84[["0","com.vaadin.shared.ui.ui.UIServerRpc","resize",["565","1916","1916","565"]
],["134","v","v",["firstvisible",["i","0"]
]],["136","v","v",["firstvisible",["i","0"]
]],["46","v","v",["selected",["s","3"]
]]]
  Mon Oct 14 13:25:45 GMT+200 2013 com.vaadin.client.VConsole
INFO: Server visit took 62ms
  Mon Oct 14 13:25:45 GMT+200 2013 com.vaadin.client.VConsole
INFO: JSON parsing took 0ms
  Mon Oct 14 13:25:45 GMT+200 2013 com.vaadin.client.VConsole
INFO: Handling message from server
  Mon Oct 14 13:25:45 GMT+200 2013 com.vaadin.client.VConsole
INFO:  * Handling resources from server
  Mon Oct 14 13:25:45 GMT+200 2013 com.vaadin.client.VConsole
INFO:  * Handling type inheritance map from server
  Mon Oct 14 13:25:45 GMT+200 2013 com.vaadin.client.VConsole
INFO: Handling type mappings from server
  Mon Oct 14 13:25:45 GMT+200 2013 com.vaadin.client.VConsole
INFO: Handling resource dependencies
  Mon Oct 14 13:25:45 GMT+200 2013 com.vaadin.client.VConsole
INFO:  * Handling meta information
  Mon Oct 14 13:25:45 GMT+200 2013 com.vaadin.client.VConsole
INFO:  * Creating connectors (if needed)
  Mon Oct 14 13:25:45 GMT+200 2013 com.vaadin.client.VConsole
INFO:  * Updating connector states
  Mon Oct 14 13:25:45 GMT+200 2013 com.vaadin.client.VConsole
INFO:  * Handling locales
  Mon Oct 14 13:25:45 GMT+200 2013 com.vaadin.client.VConsole
INFO:  * Updating connector hierarchy
  Mon Oct 14 13:25:45 GMT+200 2013 com.vaadin.client.VConsole
INFO:  * Sending hierarchy change events
  Mon Oct 14 13:25:45 GMT+200 2013 com.vaadin.client.VConsole
INFO:  * Running @DelegateToWidget
  Mon Oct 14 13:25:45 GMT+200 2013 com.vaadin.client.VConsole
INFO:  * Sending state change events
  Mon Oct 14 13:25:46 GMT+200 2013 com.vaadin.client.VConsole
INFO:  * Passing UIDL to Vaadin 6 style connectors
  Mon Oct 14 13:25:46 GMT+200 2013 com.vaadin.client.VConsole
INFO:  * Performing server to client RPC calls
  Mon Oct 14 13:25:46 GMT+200 2013 com.vaadin.client.VConsole
INFO: * Unregistered 31 connectors
  Mon Oct 14 13:25:46 GMT+200 2013 com.vaadin.client.VConsole
INFO: handleUIDLMessage: 1875 ms
  Mon Oct 14 13:25:46 GMT+200 2013 com.vaadin.client.VConsole
INFO: Starting layout phase
  Mon Oct 14 13:25:47 GMT+200 2013 com.vaadin.client.VConsole
INFO: Measured 12 non connector elements
  Mon Oct 14 13:25:48 GMT+200 2013 com.vaadin.client.VConsole
INFO: Pass 1 measured 60 elements, fired 24 listeners and did 5 layouts.
  Mon Oct 14 13:25:48 GMT+200 2013 com.vaadin.client.VConsole
INFO: Pass 2 measured 24 elements, fired 0 listeners and did 4 layouts.
  Mon Oct 14 13:25:48 GMT+200 2013 com.vaadin.client.VConsole
INFO: Pass 3 measured 7 elements, fired 0 listeners and did 1 layouts.
  Mon Oct 14 13:25:48 GMT+200 2013 com.vaadin.client.VConsole
INFO: Pass 4 measured 1 elements, fired 0 listeners and did 1 layouts.
  Mon Oct 14 13:25:48 GMT+200 2013 com.vaadin.client.VConsole
INFO: Pass 5 measured 6 elements, fired 1 listeners and did 0 layouts.
  Mon Oct 14 13:25:48 GMT+200 2013 com.vaadin.client.VConsole
INFO: No more changes in pass 6
  Mon Oct 14 13:25:48 GMT+200 2013 com.vaadin.client.VConsole
INFO: Total layout phase time: 1750ms
  Mon Oct 14 13:25:48 GMT+200 2013 com.vaadin.client.VConsole
INFO:  Processing time was 3625ms for 9734 characters of JSON
  Mon Oct 14 13:25:48 GMT+200 2013 com.vaadin.client.VConsole
INFO: Referenced paintables: 70
  Mon Oct 14 13:25:48 GMT+200 2013 com.vaadin.client.VConsole
INFO: Starting layout phase
  Mon Oct 14 13:25:48 GMT+200 2013 com.vaadin.client.VConsole
INFO: Measured 12 non connector elements
  Mon Oct 14 13:25:48 GMT+200 2013 com.vaadin.client.VConsole
INFO: Pass 1 measured 4 elements, fired 1 listeners and did 1 layouts.
  Mon Oct 14 13:25:48 GMT+200 2013 com.vaadin.client.VConsole
INFO: Pass 2 measured 2 elements, fired 0 listeners and did 1 layouts.
  Mon Oct 14 13:25:48 GMT+200 2013 com.vaadin.client.VConsole
INFO: Pass 3 measured 8 elements, fired 1 listeners and did 1 layouts.
  Mon Oct 14 13:25:48 GMT+200 2013 com.vaadin.client.VConsole
INFO: Pass 4 measured 8 elements, fired 3 listeners and did 0 layouts.
  Mon Oct 14 13:25:48 GMT+200 2013 com.vaadin.client.VConsole
INFO: No more changes in pass 5
  Mon Oct 14 13:25:48 GMT+200 2013 com.vaadin.client.VConsole
INFO: Total layout phase time: 344ms
  Mon Oct 14 13:28:10 GMT+200 2013 com.vaadin.client.VConsole
INFO: Sending heartbeat request...
  Mon Oct 14 13:28:10 GMT+200 2013 com.vaadin.client.VConsole
INFO: Heartbeat response OK
  Mon Oct 14 13:28:10 GMT+200 2013 com.vaadin.client.VConsole
INFO: Scheduling heartbeat in 300 seconds

Our performance profile for screen with one big table (20 columns, 100 rows) in IE8:

Measure height in 10848 ms. Invoked 324 times (33.5 ms per time, min 0 ms, max 260 ms).
 layout PostLayoutListener for CubaGroupTableConnector in 5525 ms. Invoked 5 times (1110 ms per time, min 0 ms, max 5530 ms).
 layout PostLayoutListener for CubaTreeTableConnector in 1027 ms. Invoked 5 times (205 ms per time, min 0 ms, max 775 ms).
 layoutHorizontally() for CubaGroupTableConnector in 809 ms. Invoked 4 times (202 ms per time, min 0 ms, max 488 ms).
 updateFromUIDL for CubaGroupTableConnector in 765 ms.
 updateFromUIDL for CubaTabSheetConnector in 432 ms.
 layout() for CubaTabSheetConnector in 429 ms.
 layout() for TabsheetConnector in 429 ms. Invoked 2 times (215 ms per time, min 0 ms, max 429 ms).
 updateFromUIDL for TabsheetConnector in 418 ms.
 layout() for VerticalSplitPanelConnector in 413 ms.
 updateFromUIDL for CubaTreeTableConnector in 404 ms.
 layoutHorizontally() for CubaTreeTableConnector in 387 ms. Invoked 4 times (96.8 ms per time, min 0 ms, max 387 ms).
 Dumping state changes to the console in 320 ms.
 LayoutManagerIE8.performBrowserLayoutHacks in 313 ms. Invoked 13 times (24.1 ms per time, min 14 ms, max 34 ms).
 ComputedStyle.getIntProperty in 203 ms. Invoked 3888 times (0.0522 ms per time, min 0 ms, max 31 ms).
 Fire ConnectorHierarchyChangeEvent for PopupButtonConnector in 153 ms. Invoked 17 times (9 ms per time, min 0 ms, max 28 ms).
 new ComputedStyle in 91 ms. Invoked 324 times (0.281 ms per time, min 0 ms, max 31 ms).
 Measure margins in 90 ms. Invoked 324 times (0.278 ms per time, min 0 ms, max 17 ms).
 AbstractConnector.fireEvent statePropertyHandlerManagers in 84 ms. Invoked 45 times (1.87 ms per time, min 0 ms, max 14 ms).
 AbstractConnector.onStateChanged in 70 ms. Invoked 126 times (0.556 ms per time, min 0 ms, max 14 ms

Chrome:

[code]
layout PostLayoutListener for CubaGroupTableConnector in 160 ms. Invoked 5 times (32 ms per time, min 0 ms, max 158 ms).
updateFromUIDL for CubaGroupTableConnector in 93 ms.
layout PostLayoutListener for CubaTreeTableConnector in 49 ms. Invoked 5 times (9.8 ms per time, min 0 ms, max 45 ms).
updateFromUIDL for CubaTabSheetConnector in 49 ms.
ComputedStyle.getIntProperty in 36 ms. Invoked 3828 times (0.0094 ms per time, min 0 ms, max 1 ms).
Fire ConnectorHierarchyChangeEvent for PopupButtonConnector in 29 ms. Invoked 17 times (1.71 ms per time, min 1 ms, max 8 ms).
AbstractConnector.onStateChanged in 26 ms. Invoked 126 times (0.206 ms per time, min 0 ms, max 11 ms).
Layout measure from tree in 22 ms. Invoked 18 times (1.22 ms per time, min 0 ms, max 20 ms).
Measure height in 21 ms. Invoked 319 times (0.0658 ms per time, min 0 ms, max 4 ms).
updateFromUIDL for TabsheetConnector in 17 ms.
Layout measureAll in 16 ms.
AOLC.updateInternalState in 15 ms. Invoked 36 times (0.417 ms per time, min 0 ms, max 3 ms).
LayoutManager phase init in 14 ms. Invoked 6 times (2.33 ms per time, min 3 ms, max 11 ms).
LayoutDependency.markSizeAsChanged scrollbars in 11 ms. Invoked 223 times (0.0493 ms per time, min 0 ms, max 3 ms).
updateFromUIDL for CubaTreeTableConnector in 11 ms.
Overflow fix reflow in 10 ms. Invoked 6 times (1.67 ms per time, min 0 ms, max 4 ms).
layoutHorizontally() for CubaGroupTableConnector in 10 ms. Invoked 4 times (2.5 ms per time, min 0 ms, max 7 ms).
Measure borders in 8 ms. Invoked 319 times (0.0251 ms per time, min 0 ms, max 3 ms).
Overflow fix restore in 8 ms. Invoked 6 times (1.33 ms per time, min 0 ms, max 4 ms).
JsonDecoder.decodeObject meta data processing in 8 ms. Invoked 577 times (0.0139 ms per time, min 0 ms, max 1 ms).

[/code] Cuba* components - simple descendants of vaadin components without custom layout logic

Some details:

  1. element.getBoundingClientRect() is very slow in IE8, on screen with one table:

element.getBoundingClientRect() in 11110 ms. Invoked 324 times (34.3 ms per time, min 0 ms, max 288 ms).

  1. Layout hacks for IE8 invoked on every step of layout:

LayoutManagerIE8.performBrowserLayoutHacks in 336 ms. Invoked 13 times (25.8 ms per time, min 15 ms, max 43 ms).

  1. JS method parseIntNative is slow in IE8:

parseIntNative in 123 ms. Invoked 3888 times (0.0316 ms per time, min 0 ms, max 16 ms).
In Chrome we have 0.00xx ms per time.

  1. I think that ComputedStyle#getProperty(String name) is a “God method”. Need to extract separate methods: getPaddingProperty, getBorderProperty, getMarginProperty to reduce unnecessary checks. But it is not a bottleneck, just a little optimization.

Vaadin 7 makes a lot of JS calculations and layout steps.

IE8 Performance log from Vaadin Quick Tickets Demo (more than 1 sec for render very simple transactions page)

Time to open page: 3200 ms! (Server visit only 400 ms)

Variable burst to be sent to server:
   154 (class com.vaadin.client.ui.table.TableConnector) :
      v.v(firstvisible : 0)
   85 (class com.vaadin.client.ui.nativebutton.NativeButtonConnector) :
      com.vaadin.shared.ui.button.ButtonServerRpc.click([LEFT,50,240,false,false,false,false,1,50,44]
)
Making UIDL Request with params
: 566eeb4c-baef-4427-8248-93ac51ee3707[["154","v","v",["firstvisible",["i","0"]
]],["85","com.vaadin.shared.ui.button.ButtonServerRpc","click",[{"type":"1", "metaKey":false, "relativeX":"50", "relativeY":"44", "shiftKey":false, "ctrlKey":false, "button":"LEFT", "clientX":"50", "clientY":"240", "altKey":false}]
]]
Server visit took 191ms
JSON parsing took 0ms
Handling message from server
 * Handling resources from server
 * Handling type inheritance map from server
 * Handling type inheritance map from server completed: 11 ms
Handling type mappings from server
Handling resource dependencies
 * Handling meta information
 * Creating connectors (if needed)
 * Updating connector states
 * Handling locales
 * Updating connector hierarchy
 * Sending hierarchy change events
 * Running @DelegateToWidget
 * Sending state change events
 * Passing UIDL to Vaadin 6 style connectors
 * Performing server to client RPC calls
* Unregistered 19 connectors
handleUIDLMessage: 291 ms
Starting layout phase
Measured 20 non connector elements
Pass 1 measured 20 elements, fired 11 listeners and did 0 layouts.
Pass 2 measured 6 elements, fired 1 listeners and did 2 layouts.
No more changes in pass 3
Total layout phase time: 651ms
 * Dumping state changes to the console
UIDL: undefined
Processing time was 975ms for 4805 characters of JSON
Referenced paintables: 26
Starting layout phase
Measured 20 non connector elements
Pass 1 measured 2 elements, fired 0 listeners and did 1 layouts.
No more changes in pass 2
Total layout phase time: 67ms
Starting layout phase
Measured 20 non connector elements
Pass 1 measured 2 elements, fired 0 listeners and did 1 layouts.
No more changes in pass 2
Total layout phase time: 34ms
Variable burst to be sent to server:
   163 (class com.vaadin.client.ui.table.TableConnector) :
      v.v(pagelength : 27)
      v.v(firstToBeRendered : 0)
      v.v(lastToBeRendered : 81)
      v.v(firstvisible : 0)
      v.v(reqfirstrow : 15)
      v.v(reqrows : 67)
Making UIDL Request with params: 566eeb4c-baef-4427-8248-93ac51ee3707[["163","v","v",["pagelength",["i","27"]
]],["163","v","v",["firstToBeRendered",["i","0"]
]],["163","v","v",["lastToBeRendered",["i","81"]
]],["163","v","v",["firstvisible",["i","0"]
]],["163","v","v",["reqfirstrow",["i","15"]
]],["163","v","v",["reqrows",["i","67"]
]]]
Postponed rowfetch
Server visit took 269ms
JSON parsing took 0ms
Handling message from server
 * Handling resources from server
 * Handling type inheritance map from server
Handling type mappings from server
Handling resource dependencies
 * Handling type mappings from server completed: 11 ms
 * Handling meta information
 * Creating connectors (if needed)
 * Updating connector states
 * Handling locales
 * Updating connector hierarchy
 * Running @DelegateToWidget
 * Sending state change events
 * Passing UIDL to Vaadin 6 style connectors
 * Performing server to client RPC calls
* Unregistered 0 connectors
handleUIDLMessage: 347 ms
Starting layout phase
Measured 20 non connector elements
Pass 1 measured 14 elements, fired 0 listeners and did 0 layouts.
No more changes in pass 2
Total layout phase time: 34ms
 * Dumping state changes to the console
UIDL: undefined
Processing time was 403ms for 10751 characters of JSON
Referenced paintables: 26

As you can see from the range of times (minimum and probably also typical time spent 0ms, but some calls take a long time), the delays are not so much on the side of the JavaScript but in the reflows that the browser makes. See below for more.

The method forces a reflow because one is actually needed to be able to get correct values from the browser as a basis of the next layout pass. I would say that even if it would be possible to avoid many other reflows, these would always need to be there for layouting to work correctly.

This comes down purely to the speed of the JavaScript engine - note that the method parseIntNative() is a recent optimization that did shave off some hundreds of ms from the previous approach in cases like that (on IE8 - this was always very fast on modern browsers).

Maybe the method could be split to optimize it, on modern browsers the impact would probably be minimal but on IE8 it might be noticeable. The old method would still be needed for getting any “random” property, but the methods getting the margin, padding and border could use separate implementations (or perhaps be fully native optimized JS methods).

Note that there is a very good reason why the all the margin/border/padding values are measured together in one block rather than separately: when you go from executing JS to measuring things, a reflow can be needed and measuring all of them in one block is much faster in IE8 (and many other browsers) than measuring one of them, making a change in the DOM and then measuring another one. Measuring the second and the third after measuring the first is almost free.

Nevertheless, what is really killing the layout performance on IE8 in most cases is reflows in the browser, not JS execution time even though the JS engine in IE8 is orders of magnitude slower than that of e.g. Chrome. There are also some slow parts in JS, but usually when you see methods often taking 0ms and occasionally a lot of time, it is because some invocations require a reflow.

In short, although small tuning can be done here and there, the only way I see to get a major speedup on IE8 would be to significantly reduce the number of reflows that layouting needs. That in turn would reflect to many of the methods that seem to take a long time. Reducing reflows might be possible, but would probably require changes much higher up in the layout strategy and still resorting to an approach like the current one in situations where the shortcuts cannot be applied.

For some background, see also
this video
on layouting in Vaadin.

EDIT: Just noting that layouting isn’t the only slow part, but often takes twice as much time as the slow parts of parsing and processing messages from the server so layouting would still be the first logical place to focus on for optimization.

Hello all,

Same behavior here. Unacceptable response time from UI when using IE8. All is fine if using other browsers (IE9 / FF / Chrome).
We tried the kb175500 trick, but with no result.
We really need a hack on the Vaadin/GWT side to increase IE8 perfs. It is just actually unusable.
We are working with Vaadin 7.1.7.

Is there any work on this issue ? I could not find any ticket in trac with some activity.

Best regards

I’ve posted ticket to trac:
http://dev.vaadin.com/ticket/12797

Hi all,

I made a two identical small application with vaadin 6 and 7: 3 textfiled, 1 button and table.
In this application you can change number of columns, rows of a table and count of parent verticalboxes for table at runtime.

I tested my application on win7 with ie8, corei5, 5Gb.

differences between vaadin 6 and vaadin 7 for rendering table with 60 rows and 30 columns:

1 parent vertical box: 1sec vs 1,8 sec
3 parent vertical box: 1,3sec vs 3.6sec
6 parent vertical box: 1,5sec vs 5,5sec

I think there is no enterprise app which can avoid nested layouting. IE8 is a common browser for many companies.
I really hope that Vaadin can fix perfomance issue with IE8.

I attached my examples.to run it please use mvn package jetty:run. 8086 for vaadin 6 and 8087 for vaadin7

Thanks
13244.zip (8.39 KB)
13245.zip (8.44 KB)

Hi.

Just confirming that we too are suffering absolutely horrendous performance on IE 8 (using Vaadin 7.1.6).

Everything works great (and is certainly better than Vaadin 6) on Chrome, Firefox & IE10. Unfortunately, IE8 is

significantly

worse. In fact, it’s completely unusable, and a show-stopper.

(Note that we create dynamic screens that can produce complicated layouts, with a fair degree of nesting, and so whilst the Vaadin 7/IE8 combination is a show-stopper for us, it may not be as bad for other users with more basic screens/applications).

Cheers,
Lee.

hi, i havethe same problem as u,do u have any suggestion?thanks!