This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Copied and pasted from a message I posted on nbdev From: Trung Duc Tran <Trung.Duc.Tran@Sun.COM> Subject: [nbdev] PERF: _huge_ startup time regression - blame ui/welcome module? To: nbdev@netbeans.org Date: Tue, 04 Jun 2002 15:16:17 +0200 I am back after two week vacation, anxious to try out the latest and greatest features in the IDE and suddenly noticed that the startup is way too long. I did some quick measurentments Config: Pentium III 500 MHz, 256 MB RAM, Linux 2.4.18, glibc 2.2.5, JDK 1.4.0, NB built from today's CVS Startup time: 35 seconds This is almost as bad as in NB 3.2 times. After looking around a little bit I disabled the new welcome module and did the measurements again. Now it's ony 25 seconds, more or less what I would expect. It looks like the new welcome screen adds 10 more seconds to the startup time, it's 40% regression which virtually negates all the hard work we did for startup time in the previous release cycle. With all due respect to the usefulness of the new welcome module I don't think it can justify the additional 40% of startup time especially when it claims to help improve the out-of-the-box experience. Long startup time definitely does not contribute to good user experience. The owner(s) of ui/welcome module, please do something about it, otherwise I vote to remove it from the standard distribution because in current state it does not qualify for our performance criteria. Thanks for your attention -- Trung
added PERFORMANCE keyword
Is the performance hit only when the welcome screen is actually visible, or actually part of restoring the module itself?
Possible regression factors: 1) HTML parsing/rendering of JEditorPane 2) Anti-aliasing turned on in editor 3) Using CSS style sheets to format HTML inside JEDitorPane 4) Fonts inside HTML
Fonts are the major contributors on JDK1.3, but even on JDK1.4 (where the font issues are fixed), there is quite noticeable slowdown, which is caused by the HTML layouting code, where WS's call to validate() during startup spends >3s in layouting the HTML pane, while it spends only ~24ms when WP is closed. Part of the validation time is consumed by instantiation of inlined objects (TipPanel:1.1s), while on JDK13 these are instantiated before and used differently (different HTML pages). Some numbers from my machine: JDK1.4: new WelcomeComponent(): 0.53s MainWin.revalidate(): 3.178s, contains new TipPanel - 1.1s JDK1.3: new WelcomeComponent(): 6s, contains new TipPanel - 4.8s MainWin.revalidate(): 1.4s If there is no WP, it takes ~24ms to MW.revalidate() on both JDKs. I'd suggest using sme profiling tool to get better picture of what is going on inside.
Some numbers from my machine : CPU Model: Pentium III (Coppermine) Frequency: 860 MHz FPU: yes MMX: yes BogoMIPS: 1717.04 Memory : Total: 384 MB I have tested welcome module and its regression when it contains WelcomeComponet with welcome content and regression of welcome module with empty WelcomeComponent. Here are results: jdk1.4 with classic TopComponet -Preparation finished, took 29553ms with empty TopComponent -Preparation finished, took 28075ms difference(classic - empty) - 1478ms without welcome module -Preparation finished, took 17630ms difference(with WM - without WM) - 11923ms jdk1.3.1 with classic TopComponet - Preparation finished, took 30493ms with empty TopComponent - Preparation finished, took 25799ms difference(classic - empty) - 4694ms without welcome module - Preparation finished, took 14431ms difference(with WM - without WM)- 16062ms It looks that there is big contribution of module initialization.
I don't think this kind of measurement is correct, there have to be some hidden cost in even empty WP TopComponent (old serialized state?) I've tried starting with Welcome module, without it and then with one more TC open, and times are (stopwatch till rendered on 1.4) with welcome module: ~37s without WM: ~30s without WM but with output window opened: ~31s
It would be a good idea to have a checkbox on the Welcome screen to disable this module. I shouldn't have to go digging into the ever increasing options list to disable it.
> It would be a good idea to have a checkbox on the Welcome screen > to disable this module. I don't think so. It would be enough to fix the problems in the Windows System lazy loading. Then it would be enough to close the welcome screen and it won't bother you any more and won't slowdown the startup by more than a few millis, which is IMHO equivalent to disabling it.
OK, I've modified WelcomeComponent to not get loaded any more after user closes it so now there is no need to disable the module. It was loaded (not necesarilly shown) by WindowsSystem when its mode (editor) was opened thus slowing down startup/editor opening.
Peter's measurement discover that if we use simple links instead of embede objects and JPanel instead of right part of page, we can safe 50% of time.This technique is already used for jdk1.3.1 because there embeded objects can't work. So I rewrote code of ContentPanel.
Created attachment 6823 [details] diff of changes in trunk
Fixed.
Just to make sure: does fixed mean you have saved 50% of the slowdown? So you made it from 7s --> 3.5s. Still 10% of the whole startup if I read your posts right. Please tell me I am wrong! Thanks for additional information.
You are rigth. There is still startup regression. (At first glance I think that there should be 20% left). Maybe Peter could provide more details.
Created attachment 6829 [details] diff of changes in trunk - also font's setting in tip panel removed
To david: If you're about to load 200 classes of the Swing HTML editor kit, if can't be for free. If you're about to open and render one more component with complex View layout, it can't be for free. If you'll close the Welcome panel, it will be virtually free the next start (it will cost you about 8ms - module presence processing) and that's it. When talking about regression in startup time, we have to compare apples with apples: we were measuring the startup time without the welcome panel in prevois releases. From this point of view the new welcome panel is not a regression in startup time... Review: You mean to apply both patches, right? Then OK.
Fixed in release 34 (both patches).
closed