Performance test reports that the following classes are loaded on NetBeans startup with LimeWare project:
Please don't load these classes unless they are really necessary.
Created attachment 70421 [details]
What is "the LimeWare project" ? Is it this: http://www.limeware-cms.com ?
retrieval for features like code completion, go to declaration, go to symbol, etc).
Therefore, I believe it is correct for the below classes to be loaded after project open of a PHP project containing
By the way, can you define what it means to start up NetBeans with an open LimeWare project? Is it the first open, or
does it first open the project, then close the IDE, then restart the IDE and measure the loaded classes? I believe that
in the second case, assuming no files are actually open in the editor, and the tasklist window is not open, then
I'm closing this as not a but - please reopen if I misunderstood something.
Sorry for incorrect project name. I've already sent you the link to the project.
How do I reproduce this problem?
I downloaded the lime6 project, and started the IDE with a clean user directory and the startup flag -J-verbose:class to
see classes loaded.
./netbeans --userdir /tmp/whatever -J-verbose:class > /tmp/classes-loaded.txt
I opened the project, and waited for the Tasklist to finish its complete scan.
At that point, there were a lot of classes loaded:
% wc classesloaded.txt
9519 38044 1446573 classes-loaded.txt
(There were 8 classes related to refactoring that showed up which is why I filtered it down to non-refactoring classes
above). These two classes are loaded because the tasklist is open; without it they would not be.
Am I using the wrong diagnostics flags? If so, can you tell me how to reproduce the problem? (The wiki link,
http://wiki.netbeans.org/FitnessViaWhiteAndBlackList would be a good place to include this info).
*** Issue 148079 has been marked as a duplicate of this issue. ***
List of classes from issue 148079:
I updated wiki page (http://wiki.netbeans.org/FitnessViaWhiteAndBlackList) with instructions.
We use slightly different scenario in our test. We open LimeWire project, stop IDE and then start it measuring classes.
Classes are measured using test described on wiki.
I see the problem now. Even though this project is a Java project, it looks like the Groovy project listens on the
project open hook, and registers the Java classpath with GSF as well. As a result, GSF goes and looks at the classpath,
Martin/Matthias/Tomas -- is this correct behavior? Is having Groovy support installed going to mean that all Java
projects will get treated as potentially Groovy (and therefore GSF) projects? I would have thought there would be some
setting on the project that you could use to enable this (which would also control whether the Groovy runtime is
included, whether the Groovy compiler is used by the build step, and so on). If there is such a setting, then the
GsfClasspathHook in groovy.support should probably use it to only register Java paths for Groovy enabled projects.
If this is as intended, then this seems problematic - and the extra runtime checking (directory scanning) is a bigger
performance problem than extra loaded classes.
It's bug for sure, something like that should happen only if groovy is enabled for the J2SE project.
Should be fixed in #122bb32e53b3 later today
Integrated into 'main-golden', will be available in build *200810031107* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Martin Adamek <firstname.lastname@example.org>
Thanks for the fix. Almost all classes are gone, but there are two that are still being loaded:
Should I file a separate issue for them?
Created attachment 71194 [details]
Those two classes are loaded because the tasklist is visible. And Task Providers are initialized with their display name
(must be passed to superclass constructor), the display name isn't requested when needed. And the GSF tasklist is
initialized with the name of its languages such that the filter makes sense to users. And the language display names are
provided by language config classes - the two classes this issue is about. Yes, this could be done separately
(declaratively) but that isn't the case yet. This definitely doesn't feel like a P2 for a handful of classes.
Verified. Filed another issue 149280 to track these two files.