-
-
Notifications
You must be signed in to change notification settings - Fork 738
Description
Memory optimization oportunity
watching rector in e.g. htop while running on a big project (e.g. mautic) we can easily see that most of the memory used is within the worker processes
these processes start small and grow over time. the more files a worker has processed, the more memory it hogs.
since we disabled the garbage collector the memory is all time growing.
this means in the end of the analysis the workers contain a lot of allocated memory, which leaked from all the files on their way thru the codebase, which was never freed because no GC.
since we disabled the GC intentionally to improve performance, I think we should limit the number of files a worker processes.
if a worker would die after X amount of files and a new worker would be spawned (so the overall number of workers would still be stable), we would free the memory and rector would need less memory.
I had a look into the codebase but could not find the right parts to implement the idea.
parallel stuff is a bit distributed across classes which made it hard for me to start.
maybe @TomasVotruba or @samsonasik have a better idea of the parallel infrastrutcture, so we could e.g. limit each workers files to be processed to e.g. 10x the job-size or similar. wdyt?
