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.
Summary: | A bucket of startup time optimizations | ||
---|---|---|---|
Product: | platform | Reporter: | _ tboudreau <tboudreau> |
Component: | -- Other -- | Assignee: | Petr Nejedly <pnejedly> |
Status: | RESOLVED DUPLICATE | ||
Severity: | blocker | CC: | anebuzelsky, gsporar, issues, jglick, jtulach, pjiricka, pnejedly, rkubacki, rstrobl |
Priority: | P3 | Keywords: | PERFORMANCE |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
Async project loading (also should apply the welcome screen patch w/ this one)
core/bootstrap patches core/startup patches core patches filesystems patches datasystems patches Module system patches Welcome screen patches (so it updates recent projects once project data is loaded) |
Description
_ tboudreau
2007-09-26 23:50:22 UTC
Created attachment 49617 [details]
Async project loading (also should apply the welcome screen patch w/ this one)
Created attachment 49618 [details]
core/bootstrap patches
Created attachment 49619 [details]
core/startup patches
Created attachment 49620 [details]
core patches
Created attachment 49621 [details]
filesystems patches
Created attachment 49622 [details]
datasystems patches
Created attachment 49623 [details]
Module system patches
Created attachment 49624 [details]
Welcome screen patches (so it updates recent projects once project data is loaded)
Tim, Thanks for your optimizations. Some of them are worthwhile, especially the module list initialization, which really stands out in the startup profile with our current module set. We shouldn't target some of your microoptimizations, though, especially locking related, as this is better solved by JDK. Some of the patches are in fact unrelated to the startup optimization and you'd better file them as separate issues for individual maintainers. I'll go through your list later next month. > We shouldn't target some of your microoptimizations, though, especially locking related, as this is better solved by JDK.
Re the replacement of Stack and StringBuffer - aren't the optimizations that reduce the cost of synchronization in the JDK mainly in JDK 6? For the case of Mac
OS X, the last rumor I heard is that the only way to get JDK 6 on Mac may be via buying an OS upgrade. So if they do make a difference on JDK 5 on Mac, and
are otherwise harmless (addition of one class - an ArrayList subclass the replicates the pop() and push() methods of Stack), it seems like it would do no harm
to apply them. If I'm wrong about most of that work being in JDK 6, of course, we can forget it.
I'm in Prague this week, so perhaps we can sit down and go through some of these.
Notes: 1. Idiom: boolean asserts = false; assert asserts = true; if (asserts) { // more expensive checking } 2. Logging in FileLock is useful. Replace with: private FileLock() {} public static FileLock create() { boolean asserts = false; assert asserts = true; return asserts ? new LoggingFileLock() : new FileLock(); } private static class LoggingFileLock extends FileLock { protected void finalize() { if (!valid()) {Logger.log(.....);} // or throw AssertionError, etc. } } 3. Dependency optimizations: can probably be replaced by clever regexps. (%2 == 0 trick is to catch e.g. "foo..bar".) DependencyTest should already check all the corner cases - make sure it still passes! 4. SpecificationVersion would need svuid. 5. Do not catch NoClassDefFoundError. Ignore this patch. Mostly future, but I'm trying to het the module list cache to 6.0 I was experimenting with module list cache and the results are not as good as expected (on Linux, at least). The problem is that the up-to-date check alone is quite expensive, as it needs to locate the module files (for up-to-date check) in 17 folders (clusters), and stat()ing a short file is nearly as expensive as reading it. Anyway, I'm closing this as a duplicate of issue 110011 (slow cold start), with reference to this issue as source of inspiration. *** This issue has been marked as a duplicate of 110011 *** |