You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
a) During eclipse startup with many external libraries i see some seconds spend in ClasspathUtilCore.getPath
There is a simple improvement possible:
instead of if (file.exists() && file.isAbsolute())
use the inverse order:
if (file.isAbsolute() && file.exists())
since file.exists is an costly IO operation while isAbsolute() is only fast textual evaluation ("starts with slash?").
Thats not much overall but since it's so cheep to improve ... would you please ... "src.zip" is never an absolute filename!
b) A more highlevel problem is that we have a lot projects which all reference the same external libraries (like plugins\org.eclipse.core.runtime_3.24.0.v20210910-0750.jar). Kinda bad that this "exits" checks are done over and over for the same file.
c) the file "org.eclipse.osgi_3.17.100.v20211104-1730.jar\src.zip" will also never exist.... because that "jar" is not an directory but an archive... i guess pde does somewhere know its not a "dir" shaped bundle. - i just do not know where that information is stored.
Stacktrace is for example:
at org.eclipse.pde.internal.core.ClasspathUtilCore.getPath(ClasspathUtilCore.java:220)
at org.eclipse.pde.internal.core.ClasspathUtilCore.getSourceAnnotation(ClasspathUtilCore.java:186)
at org.eclipse.pde.internal.core.PDEClasspathContainer.addExternalPlugin(PDEClasspathContainer.java:80)
at org.eclipse.pde.internal.core.RequiredPluginsClasspathContainer.addPlugin(RequiredPluginsClasspathContainer.java:352)
at org.eclipse.pde.internal.core.RequiredPluginsClasspathContainer.addDependency(RequiredPluginsClasspathContainer.java:297)
at org.eclipse.pde.internal.core.RequiredPluginsClasspathContainer.addDependency(RequiredPluginsClasspathContainer.java:309)
at org.eclipse.pde.internal.core.RequiredPluginsClasspathContainer.addDependency(RequiredPluginsClasspathContainer.java:280)
at org.eclipse.pde.internal.core.RequiredPluginsClasspathContainer.computePluginEntries(RequiredPluginsClasspathContainer.java:162)
at org.eclipse.pde.internal.core.RequiredPluginsClasspathContainer.getClasspathEntries(RequiredPluginsClasspathContainer.java:112)
at org.eclipse.jdt.internal.core.JavaModelManager.containerPutIfInitializingWithSameEntries(JavaModelManager.java:780)
The text was updated successfully, but these errors were encountered:
Get rid of some File.isFile() I/O where it is impossible that such file
exists anyway:
"file.jar/src.zip"
"directory/absoulteFileName"
In my usecase it reduces getSourceAnnotation() from 3sec to 1.2sec
Signed-off-by: Joerg Kubitz <[email protected]>
a) During eclipse startup with many external libraries i see some seconds spend in ClasspathUtilCore.getPath
There is a simple improvement possible:
instead of
if (file.exists() && file.isAbsolute())
use the inverse order:
if (file.isAbsolute() && file.exists())
since file.exists is an costly IO operation while isAbsolute() is only fast textual evaluation ("starts with slash?").
Thats not much overall but since it's so cheep to improve ... would you please ... "src.zip" is never an absolute filename!
b) A more highlevel problem is that we have a lot projects which all reference the same external libraries (like plugins\org.eclipse.core.runtime_3.24.0.v20210910-0750.jar). Kinda bad that this "exits" checks are done over and over for the same file.
c) the file "org.eclipse.osgi_3.17.100.v20211104-1730.jar\src.zip" will also never exist.... because that "jar" is not an directory but an archive... i guess pde does somewhere know its not a "dir" shaped bundle. - i just do not know where that information is stored.
Stacktrace is for example:
The text was updated successfully, but these errors were encountered: