Community
Participate
Working Groups
Created attachment 281819 [details] Threads showing the beavior Running with lombok and CodeMining features (both are really awesome) creates high and long time running loads where it seems like it's trying to traverse the CU's over and over again. If you are fast enough (which isn't hard to be in this scenario), CodeMining launches more and more "processing" threads hogging up all cores, which seems to never end unless you leave the machine for a couple of hours. Disabling CodeMining removes/fixes this behavior. Attached a thread dump.
Lombok changes code behind the scenes in ways which cannot be known to JDT code mining. I would be surprised if there's even a theoretical possibility to fix this in JDT. I suggest to report this to Lombok instead: they can see all that is in JDT and adjust their tweaks and hacks accordingly. You are still invited to prove me wrong and supply a patch in JDT, in which case you may of course re-open this bug as an enhancement request.
This bug got closed way too fast. Lombok bug discussion is still ongoing: https://github.com/rzwitserloot/lombok/issues/2430 The TLDR; however: - Turning reference counting off makes this thing go away. - Running classes through delombok (turning them into regular java code in the process) and running codemining on those is *also* slow. - The fact that lombok needs to do work to generate code is probably a contributor, but it's definitely *not* the only factor.
OK, I'm moving the bug to the component where code minings are implements. If you provide a pure-java example demonstrating the slowness, perhaps they can be convinced to re-open the bug. A single stack trace for sure does not suffice to demonstrate a performance problem.
Not saying it's not at least partially lombok's fault, btw. Just saying the picture isn't necessarily clear cut - without running a profiler on this thing. The public example in the lombok thread is here: With lombok: https://github.com/rzwitserloot/lombok/blob/master/test/transform/resource/before/DataPlain.java Without lombok: https://github.com/rzwitserloot/lombok/blob/master/test/transform/resource/after-delombok/DataPlain.java The latter is that plain-java example you're interested in. I haven't personally run this but a user in the lombok bug report says that codemining needs about 2 minutes to complete codemining on both versions, provided you scroll to the end of the later file.
@Code mining experts: despite the title mentioning lombok, comment 4 gives a pure-java example were code mining "needs about 2 minutes to complete". This doesn't look good.
I imported the given file in my IDE, triggered all code minings, played a bit with the code and didn't see such a delay with regular JDT. I think the delay is caused by some other stuff, it may require Lombok plugin to be installed, some lombok properties and so on. Can you please provide more context of a test which doesn't require lombok and that you verified does cause such delays?
Did you import it into an empty or small project? I haven't tried, but from a quick look at the example, I guess the problem is that "find references" is done for multiple equals and toString methods. Doing this kind of search even for a single method is very slow in Eclipse (unless the search scope is small). IIRC Eclipse just has a simple text index to find candidate classes that use methods with that method name at all, and then parses and creates bindings for all the candidate classes (which for equals and toString often means almost all classes that are in the search scope) Improvement ideas: - Don't show the code mining for methods from java.lang.Object - Cancel calculation if the user scrolls and the mining is not visible anymore. Maybe there are currently multiple threads doing codemining calculcations. If yes, this might need to be restricted.
(In reply to Till Brychcy from comment #7) > Improvement ideas: > - Don't show the code mining for methods from java.lang.Object > - Cancel calculation if the user scrolls and the mining is not visible > anymore. Both are quite interesting. Can you please open a bug for each one of those? (first is in JDT/Text, the other is in Platform/Text)
(In reply to Mickael Istria from comment #8) > (In reply to Till Brychcy from comment #7) > > Improvement ideas: > > - Don't show the code mining for methods from java.lang.Object > > - Cancel calculation if the user scrolls and the mining is not visible > > anymore. > > Both are quite interesting. Can you please open a bug for each one of those? > (first is in JDT/Text, the other is in Platform/Text) Done: bug 562768 and bug 562765.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
