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.
JavaDataNode.checkUpToDate spawns a compiler job and does an awful lot of work just to decide if the icon should be badged or not (there's even a comment "very slow!!" in the method). The common case in NetBeans is that the user does not set the compiler output dir. So a very fast test on a class file is all that is needed in 99% of the use cases. I'm attaching a simple patch that does this faster test if a system property is set. It makes a noticable difference in the performance of opening folders. It's naively written but works (FWIW, I think the performance problem is not so much that the slower test is so slow, but the gc's it causes). What would cover all the cases better: - Check the output dir of the compiler type - if not set, use the fast test - Even faster, some static property of JavaCompilerType which returns true if there are no compilers in the system with a different output dir; if so, you don't even need to test the output dir of the current compiler. Also, probably a bug in explorer asking for icons it doesn't need - the up-to-date test really should never run unless the file is actually somehow displayed.
Created attachment 13113 [details] Naive patch to use the fast up-to-date check if a system property is set
Makes sense. Even though it is not cheap to find out all compilers and ask them for the output dir. Cc Tomas to take this into account for stavbicka
> Even though it is not cheap to find out all compilers and > ask them for the output dir. Shouldn't it be possible to do that check once per run of NetBeans unless something actually changes?
Sure, it should. But I looked at current apis and I am not aware of any that allows to find out destination folder of the compiler type. So it is possible just for java compiler types. In case of eg ant script compiler it will not work.
Well, stavbicka is a great opportunity to improve the APIs. Any case where separation of concerns results in information resolution loss (which is what this is) is probably something that should be revisited.
This issue is no longer relevant since the code was completely rewritten.