Description of problem: When running the application in debug mode everything works tremendously slow. Each browser refresh takes ~5-~10min and using the application is nearly impossible. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Alexander - should be in post with link to http://gerrit.ovirt.org/#/c/28872/? [although to my understanding, the improvement that ^^^ brings is not enough, and additional improvement need to be looked into] thanks.
Yes I want to investigate more before declaring this fixed
The latest patch posted should give a 4-5x speed improvement on logging into webadmin during GWT debug mode. It takes me around 50s now, which for now I am going to declare sufficiently quick to not be an issue anymore. We just need to verify that the changes I made don't cause any regressions.
From comment 4 I assume the performance issue in GWT debug mode is fixed for development environments. As for QA, I can verify this bug from "production" point of view - on RHEVM installed from RPMs where GWT debug mode is not enabled. From what I understood, this patch changes the way how UI presenters are initialized: - Before, all UI presenters (i.e., areas of the HTML application like main tabs, sub-tabs, etc.) were initialized when the Webadmin/UserPortal application was initialized - right after login. - Now, UI presenters are initialized only "on demand", after they're activated (i.e., at the moment some main tab or sub-tab is accessed). Which results in: 1) faster login, application is initialized quicker because it doesn't load all UI presenters - Verified: login to RHEVM 3.5 is 3+ faster than to RHEVM 3.4 on the same HW (~3 seconds vs ~10 seconds) 2) slower loading of main tabs or sub-tabs when accessing them for the first time - Verified: comparing to RHEVM 3.4, loading of a main tab or sub-tab time takes a bit more time at first, but then is fast as in 3.4 Moving to verified, rhevm-3.5.0-0.10.master.el6ev.noarch (vt2.2). If you find something from above is not true or accurate, feel free to move this bug back to ON_QA.