Slow content assist/UI freezes since 2023-09

[gigermocas]

Since eclipse release 2023-09 I'm unable to work on Eclipse on my current project due to it being extremely slow interacting with the code and experiencing a lot of UI freezes. I'm still on 2023-06, which is working fine, but I am trying to move to JDK21 and I would need a newer Eclipse's support for it, so I'm kinda stuck.

I did submit an issue here when I first encountered it in #157, but I think it was closed prematurely, the fault being mine as I should have worked on a clean eclipse installation. I then opened one specifically for the jdt: eclipse-jdt/eclipse.jdt.core#1728, but the information I provided didn't show any obvious issue to be fixed.

I was able to make a small test project that can show what I'm experiencing.
test.zip
As the content assist is also slow, it's a start up point more easily reproduced as I think both issues stem from the same problem.
I'm hoping that with this the cause for the regression can be more easily found.

I recorded a couple of screen captures exemplifying the behavior, first on a clean 2023_06 version/worksapce, and then on the lastest 2024-03:
Version: 2023-06 (4.28.0)
Build id: 20230608-1333

content_assist_2023_06.mp4

copy_text_2023_06.mp4

Version: 2024-03 (4.31.0)
Build id: 20240307-1437
(I also reproduced the same behavior when updated to I20240319-1800)

content_assist_2024_03.mp4

copy_text_2024_03.mp4

Apologies in advance for my insistence on this issue. I must admit I'm a bit overwhelmed thinking on undertaking this on eclipse's codebase myself for this and I fully understand the context around OSS projects, but with this new information and an actual sample maybe someone can more easily pick this up and can properly diagnose this.

[mickaelistria]

I've tried it locally and couldn't reproduce such a lag in completion responses with the given project.

[gigermocas]

This is on a window 11 machine, maybe it's OS specific?

Definitely something changed going from 2023-06 to 2023-09 in the same environment. Looks like it's having problems working up with the class c.OCIRequest in this example. If I remove the unused import in Test when testing content assist on it, its fast.

I've a attached some snapshots during the triggering of the content assists on both environments, and the hotspots are very different.
snapshots.zip

[gigermocas]

I was able to get the SDK going and I got a bit more information:

Both content assist logic and text selection (for copying(?)) triggers a org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(CompilationUnitDeclaration parsedUnit, boolean buildFieldsAndMethods), and since eclipse-jdt/eclipse.jdt.core@32961cf introduced a new step with TypeDeclaration.updateSupertypesWithAnnotations(), processing the file c.OCIRequest in this sample takes in my machine about 4 to 5 seconds when previously took about 40ms. It's effectively traversing the whole source code due to its annotations/imports, for this example the performance impact seems massive. In my actual project this is exacerbated because the project is bigger and the problem is expounded, making it unworkable.
I don't understand why all this annotation processing is required for these particular functions.

I guess that with this information I hope someone can confirm these findings one way or the other.

[Bananeweizen]

I can confirm it's slow. However, I guess there is no easy way out. The mentioned commit from @stephan-herrmann fixes several issues that all rely on type annotation information to be computed completely instead of doing it lazy (which happened before, and which is why you did not see the slowness then). As your generated OCIRequest class has around 8000 annotations, the parser has to parse all those sources to create the actual type information for the OCIRequest type.
I would suggest to try splitting your projects into 2, where one deals only with the generated sources and maybe a small wrapper, and the other contains your manually written code. Completion in the second project should then be fine, as long as you refer to the wrapper only. I had to do a similar split in the past with huge generated files that slowed down Xtext or Xtend.

[gigermocas]

I was dreading it was something like that.
I already have a project structure like you mentioned but I do have to create OCIRequest/OCIResponse subclasses in dependent projects, and there are a lot of them, I don't have an easy workaround that.
At least I now understand the underlying issue, thanks.

[jukzi]

I've a attached some snapshots during the triggering of the content assists on both environments, and the hotspots are very different.

@gigermocas if you can still reproduce the issue please provide sanpshot where you have NOT excluded java.** - most likely the hotspot is some file access from java.nio that is not visible in your snapshots


Anyway this seems to be an jdt issue - please reopen the issue against jdt.core (https://github.com/eclipse-jdt/eclipse.jdt.core/issues) as we can not move issues between organizations.

closing as not platform

[gigermocas]

FYI, this was picked up on the jdt side: eclipse-jdt/eclipse.jdt.core#1728 and eclipse-jdt/eclipse.jdt.core#2343