You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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 processesthese 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?
The text was updated successfully, but these errors were encountered: