just to put this post in context: we currently use Vaadin 6.7.7 (within Liferay Portal) and are evaluating the changes to be made when upgrading to Vaadin 7. Along with that evaluation I’ve created a simple Vaadin-(Portlet-)Application which just renders n components of one type (i.e. Labels or Buttons etc., whereas n can be adjusted) to get a feeling at which point the client starts to get sluggish.
So it
seems to me that Vaadin 7 (beta 7) got slower - I’ve checked the figures in the debug-window and the JSON-processing time increased (dramatically) from 6.x to 7beta7 along with the size of the JSON-response itself (which most probably correlates).
Is this something that just happens to me or can someone (or even the Vaadin-Team) confirm that observation? If it can be confirmed - will that be improved in the final release or is that something which happens due to architectual changes you’ve made? Are there any workarounds, tricks or speed-bumps I can turn on in Vaadin 7 to ease my pain?
To make my issue more precise. In a portal-environment you can end up with more than a single Vaadin-App on one page (questionable, I know). That in combination with a
seemingly slower Vaadin 7 executed in IE 8 leads me straight to a show-stopping issue.
Funny, I was coming to the forum to post similar performance issues when I saw your post. I’m working on a fresh Vaadin 7 project currently using 7 beta 9. In Firefox and Chrome the rendering/layout times aren’t too bad and seem to be much better than Vaadin 6 especially when using CssLayout. However in IE8 the performance is completely unacceptable and users are constantly getting “Stop running this script?” warnings.
The view in question is already rendered and is being dynamically updated with about 500 components (a mix of buttons and labels in CssLayouts). There are no horizontal or vertical layouts being used in the dynamically updating portion of the code. I know IE8 is pretty slow, but it is currently at >10x slower than other browsers and isn’t really usable. I know I could replace some of the CssLayouts with more hand rolled HTML and Css and replace some of the buttons with labels on a clickable layout, but at that point I’m losing a lot of the benefit of Vaadin’s component model.
I attached screenshots from an IE8 dynamic update and a Firefox dynamic update. You can see that IE8 is much slower to the point of being unusable due to the script warnings. I did notice that there is a LayoutManagerIe8 implementation so I’m wondering if it just hasn’t been completed or tuned in the beta releases?
We still need to look into the performance part and especially for IE8 it seems. I created ticket
http://dev.vaadin.com/ticket/10318 for this. Follow that ticket for progress updates. If you happen to have a good test case we can use, please attach it to the ticket.
I will help you out in this case, actually this is not the issue with Vaadin.
This is the Internet explorer issue . I have been using Wicket for my current application and a fan of Vaadin too. I got this issue in my project. We had a screen which renders thousands of html tags dynamically for various reports. Columns in table gets generated run time for various reports and number of rows depends on the screen size. We had a live update on this page for displayed rows as well. Bit complex right…
The page was made for the Pivot reporting system for a Banking project, using java script, css, html, json and wicket components. As most of the banking client does not trust open source browsers hence they were using IE 7, IE 8 in their environment and we need to support them throughout.
We got the error
“Stop running this script” while rendering happens for pivot report which holds around 50 columns in it and around 40 rows to display after which IE hangs and stop responding. This problem did not get reproduce in other browser. God, What the hell is going on in internet explorer? Is it something wrong the way we have coded our Java script ? No, Is that we have done some heavy synchronization on rendering logic? No. Then what’s the problem? We tried various ways to fix this script error but could not do so. Debugged java script , Java code re-factoring, wicket performance optimization, json rendering tools, disabled the live update, changed the way of rendering we have tried each damn thing but nothing works.
One solution was to use
Google’s chrome V8 engine but client was not ready to take it.
Finally We found the problem and the solution for this issue, interestingly it was not a code fix as we suspected. We know that IE has been a slow browser from last few years and they overcome this slowness by introducing a fix to the root cause.
Apparently IE8 has an undisclosed “limit” on the number of styles it will load without complaining. We let this Fix to add the required “Styles” Dword and create a new DWORD value called “MaxScriptStatements” set to “0xFFFFFFFF” and reloaded IE8. No more “Not Responding” and no more slow script dialog pop-up!
I looked at another system which has IE9 installed, IE9 already has the key in the regedit, so this problem do not occur there at all. Link recommends this fix as a slowness solution for the IE browser versions 4,5,6,7 and 8. We have tested it for the IE 7 and 8, it works fine and increased the speed as well.
So for the future IE performance problems we could definitely refer
http://support.microsoft.com/kb/175500 as one of the recommended fixes. This is a IE patch released by Microsoft. So do not blame any component framework it is the IE who is responsible for it hence go ahead and ask your clients to fix the IE bug by this patch.
I hope it is useful, please let me know if it does not solve your problem.
Thanks for the reply. I attached a test case to the ticket. In one way I’m glad to hear that this isn’t the final expected performance of Vaadin 7. I was afraid you guys already did the layout performance improvements in the alpha releases. Let me know if you need anymore information.
Sandeep, thanks for the information; however I think the issue here is Vaadin’s LayoutManager implementation for IE. From the debug window output and using the Firefox profiler I can see that the majority of time is spent in getting computed styles on elements during the layout phase. I was able to reproduce the issue with a simple test case (see the ticket) that only uses a handful of styles. I have the feeling the generic “stop this script” question is shown in IE if anything takes to long including JS calls or CSS selectors.
Unfortunately with MS no longer pushing IE versions to XP and most organizations stuck on XP I think we’ll be dealing with these problems for a while :-/
thx Micheal for the confirmation (and for all the groundwork along with that thread).
Just as an additional information I’d like to share with you all - I had a quick chat with Ville Ingman (Vaadins VP of German Operations) just to get a statement about the future perspectives and he also confirmed that the performance-optimization part for Vaadin 7 is still to come (so even in beta 9 the behavior is not different than in beta 7 - as you revealed Michael).
So, taking Villes word and the fact that the issue is now officially tracked in the bug-tracking-system I consider my initial question as answered now. For the moment I will stick with Vaadin 6 and will wait impatiently for the final Vaadin 7 release.
As Michael stated this issue can by no means be made IE8’s fault. We all know that it is has lousy performance compared to example webkit based browsers, but Vaadin is here to abstract away all inconveniences of web app development. Both our client and server side code should be fast enough not to block anyones work. Otherwise Vaadin has failed.
Although IE’s have progressed and other better performing browsers have gained a lot more market share, client side performance is still as critical issue as it was like 5 years ago. Client side latencies still affect usability, especially on nowadays popular mobile devices that limited CPU powers.
In theory V7 should be able to perform much better than V6 as we have dropped IE6/7 support and thus we can build component implementations in a much more modern way without all IE6 hacks. I was hoping great steps forward on the area, but IMHO being at least in par with V6 should be the minimum requirement before V7 gets out of its beta phase. If this is not yet the case,
keep posting those issues to the ticket Artur linked. Otherwise this kind of issues might be forgotten. Those sure aren’t the most inspiring things to tackle.
If you want to use more robust approach to track your applications performance characteristics, you should definitely use our Selenium based integration test product called
TestBench . It’s latest and greatest version has simple tools to measure both client side “rendering time” and the time spent by the servlet to handle your requests. If you set that into your builds before V7 upgrade, you’ll automatically spot at least major problems that might come up during the upgrade. Check out
my simple example project to see how easily you can set up such integration tests.
hi,
I’m new with Vaadin
I have a problem I am working on for days …I no longer understand anything
I use Vaadin 7.3.10 Tomee as a server, my application works very well (no apparent bugs) but after a number of uses the interface doesn’t reponds (at all) …the loading bar flashes… and nothing happens … nothing in server-side or client-side.
I do not know what to do
please help
(sorry for my english)
I hope someone from the team is still having an eye on this thread.
We got the error “Stop running this script” in IE8 in 7.3.7.
We are unable to dictate our customers to apply the registry fix or to use another browser.
In our case the issue is related to tables having about 10 columns and 10-15 rows. Even worse we are using custom column generators for all kinds of editable fileds like date choosers and checkboxes.
For IE8 only: We solved the issue by sending only one row to the table and let the table send a request to load the remaining rows. And it feels that IE8 is now performing better.
During our analysis of the vaadin client code we found a few lines that could have been different. May be you will consider these hints for future development:
http://www.w3schools.com/js/js_performance.asp → Reduce Activity in Loops
for (int i = 0; i < childNodes.getLength(); i++)
→
final int length = childNodes.getLength();
for (int i = 0; i < length; i++)
Unneccessary operations: e.g. VCalendarPanel
In our testcase the table contained 44 cells having disabled date choosers as editors. After a handfull of actions which created about 99VCalendarPanels only, the CPU profiler has shown over 56000 accesses to FlexTable and HTMLTable methods done by VCalendarPanel. According to the trace this was a hotspot that took ~10% of the execution time. if PopupDateFieldConnector#updateFromUIDL() would not modify the VCalendarPanel in case that the field is disabled especially IE8 would perform better.
Unneccessary object creation: e.g. Profiler
Wrong. Compiling with style DETAILED has shown me that the Vaadin profiler is actually lightweight.
Use tools like Eclipse to get rid of unused code and find potential null pointer accesses
E.g. TableConnector:
int previousTotalRows = getWidget().totalRows;
getWidget().updateTotalRows(uidl);
boolean totalRowsHaveChanged = (getWidget().totalRows != previousTotalRows);
The result of line 3 is never used and so line 1 is not required, too.
Is there a ticket I can use for providing patches?
