eclipse-platform
Regular expression search lock and eat a lot of RAM and CPU
I'm tring to avoid lock of eclipse 2025-03 in a normal search java file \r\n and substitute with ")\r\n or searching in any project of workspace a string.
I needs to kill Eclipse 2025-03 as process and relaunch it to work!
Other thing, Eclipse 2025-03 is eating 4Gb of RAM on windows 11 pro and on i7 1355U CPU (12 threads ) with java21 on Springboot projects with webflux reactive projects using it as IDE to write code.
Please fix all these problems about RAM/CPU eat and don't stop on UI command click of user for example in search of text in any project, please use webflux reactive to improve it.
I tried to change garbage collector with different parameters to avoid these lock of IDE without results.
Thanks a lot for your support.
I'm tring to avoid lock of eclipse 2025-03 in a normal search java file \r\n and substitute with ")\r\n or searching in any project of workspace a string.
I needs to kill Eclipse 2025-03 as process and relaunch it to work!
Can you attach a profiler to see where exactly all this time is spent? I did a search & replace in one of my smaller workspaces which took ~20s and never caused the UI to freeze or to become otherwise unresponsive.
Please fix all these problems about RAM/CPU eat and don't stop on UI command click of user for example in search of text in any project, please use webflux reactive to improve it.
For our application, I use the "Eclipse IDE for RCP developers" and even with all 1500 plugins loaded, the IDE is only barely scratching the 2GB limit during a clean build and otherwise stays at 1.2GB during normal use. So such a huge memory requirement is not something I have ever seen.
Can you create a heap dump and check which components are responsible for memory demand?
I have 45 project in Springboot 4.3.4 Webflux Java21 all reactive with Jetty and MongoDB reactive. All have a common project common library but only 3 or 4 REST projects are opened included parent, project library and 3 or 4 opened.
After you update alt + F5 by maven and clean install common library project, and final project after working one hour on code and switching on branch of common library project and 3 or 4 projects (ALT + F5 and clean install if change branch). Eclipse start eating RAM and not left without a reason or I don't know the reason. If you, after 1h of work, launch by Eclipse UI clean heap memory icon no reduce RAM reserved to Eclipse, 2 or 3 or 4GB RAM got as if it's used!
So finally Eclipse lock and I need force kill process e re launch.
System is Windows 11 Professional updated.
Thanks a lot for your support.
If we can’t reproduce the/a problem, we can’t do anything about it. Perhaps you have a bunch of additional tools/plugins installed that contribute to the memory consumption?
If you use e.g. VisualVM, you should be able to create a heap dump. That should already give an indication of which components keep all that memory locked.
You can also use VisualVM to attach a sampler which should keep track of where the time is spent while doing search & replace.
If you only use a handful of projects then that sounds like a problem that only happens in combination with your specific configuration. Which, as @merks said, is not something we can analyze if we can't reproduce this behavior.
Is there a small example you can share that has the same behavior?
It's possible to reproduce in 2025-06 M3 if you perform the same expensive search twice.
The 1st time, the UI became unresponsive for "only" 5-10 seconds but I managed to see the search results: over 12 million matches.
The 2nd time, the UI became unresponsive for little over 45s and I had to kill my IDE.
This is a VisualVM sample of the 1st search: Expensive search.zip
Here's a memory sample from the 2nd search: Expensive Search 2 (memory).zip. Maybe it is worth to do some "cleanup" before a new search starts?
This is the overall status for both searches.
All in all: an improvement would make sense but we're talking about a massive search here, I'd say we need more info to go on before we go down the rabbit hole.
@skyblackhawk can you provide more info about how you ran into the error? Did you have to perform several searches? How many matches did you have? Did you ever get to see the results?
It's possible to reproduce in 2025-06 M3 if you perform the same expensive search twice.
The 1st time, the UI became unresponsive for "only" 5-10 seconds but I managed to see the search results: over 12 million matches.
Good catch @fedejeanne. I can see the same issue on my side as well. My bet is that the culprit is the search history. If you do the same expensive search over and over again, the previous result is kept in memory until the history is manually cleared.
Which is also something very visible in the heap dump. I have four entries in my history, which correlate to the 600+MB blob that each one occupies in memory.
I'd say we need more info to go on before we go down the rabbit hole.
I'm pretty sure the main reason is string duplication. Each line that is matched by the search is stored over and over again. So you end up with e.g. 80000 instances of the line *\.
Thank you @ptziegler for the details! Indeed the problem is that lots of Strings are being created and retained in the search so the History can work. More specifically, the field LineElement.fLineContents.
Unfortunately I haven't found any simple way to get rid of the issue without having to keep even more things in the heap. One possible approach I could think of is to try and keep a reference to the file and then only extracting the line contents on demand (when one unfolds the respective item in the search view), but that is also not trivial and may have another performance implications that need to be tested.
I'm not able to put much more time to this issue but I'll keep it in the back of my head and circle back if I have any novel ideas. Maybe @skyblackhawk would like to propose a fix?