Always growing memory footprint Follow
I am happily running PHPStorm now for quite some time, but one thing is still bothering me: It seems PHPStorm is having a constantly growing memory footprint. Sometimes it lowers slightly, but over time it keeps on growing, sometimes to over 400Mb of RAM. I regularly trigger the GC manually to lower the memory footprint again, but I would expect PHPStorm to also do this as well. Am I missing something? Is there a setting I should change? Or is this simply a bug in the application?
Please sign in to leave a comment.
Basically this control is for informative purposes only and you gain absolutely nothing and even lose some performance by executing manual GC because it will collect some internal caches.
OK, so given that I should not manually trigger the GC, what can I do to make sure that the GC is automatically triggered? I do not like the always growing memory footprint of the application. Are there settings I can change to that the GC is triggered automatically and in time (so before it needs to allocate more memory to itself)?
The GC settings are not "user serviceable" part of application and is already properly tuned. Application will request to increase maximum memory settings automatically upon "out of memory" error.
I can only recommend you to switch off the heap indicator so it don't distract you too much (Settings | type "memory" into search box).
That's hardly a satisfying answer...
The fact that the application using so much memory means my system has less memory for other tasks. Hiding the memory usage information from the screen will not solve that problem, it will only stop me from seeing the problem.
Instead, I'd prefer to hear about possible steps either I can do to ensure less memory usage (PHPStorm sometimes takes over 500Mb of RAM!) or the JetBrains team will do to ensure less memory will be used or a better GC will be done. When I trigger the GC manually I see the memory usage drop quite a bit, meaning the application is able to run without using this much memory. Then why isn't the application automatically using less memory?
PhpStorm a Java application, and on GC memory is NOT released back to host OS, so basically you gain nothing by executing manual GC.
You slightly decrease amount of actively accessed memory but reset most internal caches.
Note that application is set up to use 500M of heap memory, actual memory usage will be larger, depending on OS.
I gain nothing by executing manual GC except for postponing/preventing the app from claiming more memory.
I wonder... does this mean that PHPStorm always claims an immense amount of memory, even if it isnt using it?
All Java applications currently will claim up to maximum allowed heap and never release it back to OS - GC is just managing stuff inside this in-process heap. There's nothing specific in PhpStorm. Heap limit for PhpStorm is chosen during testing on medium and big real open source projects - its enough majority of cases in terms of application performance.
I've been using this tool now for awhile and finally noticed that there's a "lot" of heap being used for the simple mouse movements. If you find your memory building, 155MB -> 200MB, and then stop your mouse, the 200MB stays at 200MB for a loong time,... simply moving your mouse again, makes the cache continue from 200MB and with 1MB chunks getting eaten up at a time...
this is a growing concern for me too - as it seems there's a bit of careless and inefficient caching/memory usage...
anyways to streamline this... at least for the simple mouse movement issues?
I repeat: unless you experience OutOfMemory Exceptions you should never pay attention to heap size indicator.
right, i totally read the entire thread... not trying to be a pain, but one DOES experience burst cache issues when your software is nearing 200MB, 350MB etc... and yes i does indeedy affect overall computer performance, even with a mother ship of a machine... because it affects the caching on the chip itself.
not trying to be a pain, but why on Earth would the cache be needing to silo-ize/store the 'mouse' movements without dumping where they've been 1-2 minutes ago!? (heck, 3-4 seconds ago is fine)
probably depends on your system memory .
I use an iMac with several Gb.
At around 600M of 791M it becomes so slow and unsable that I have to quit and reopen the app
I do belive that there is some issue here.
I have the same problem. Even if we "should never pay attention to heap size indicator", I use it as an indicator of how long I have before I have to restart PHPStorm.
My max is 790, but as soon as it gets close to 690, I need to start finishing off what I'm doing and force a restart before it hangs or beachballs so badly that I have to force quit. At the moment I'm having to restart the app every 2-3 hours. Sometimes I have to force quit before this point and have lost work.
I've tried doing the WebIDE cache directory clear, uninstalling the app clean and reinstalling it. But it's driving me batty, and having to restart the IDE every few hours is pretty disruptive.
What causes the growing footprint, and what can I do to resolve the issue?
Edit: Running Snow Leopard 10.6.8 with 8GB RAM
I'm experiencing the same problem. The in-use memory amount for phpStorm infinitely increases until it locks up my system or I manually restart it.
I'm talking up to 1GB of memory before my system is unusable.
I'm on Mac OSX Lion.
Same issue. I'm currently working in an environment where 3 other people have identical hardware, VM's on the hardware running a local web server, and are working on the same web site. Their pages are loading in 1 second, and mine were taking 30+. The difference is that I'm using phpstorm and they're using VI. phpstorm was using almost a gig of memory. I'm thinking that memory usage is becoming as passe a concern in app architecture as disk space.
Please follow http://devnet.jetbrains.net/docs/DOC-1253 / Memory snapshot section and provide a snapshots for the case when memory is get all used up for you.
Also a CPU snapshots for 5 minutes of IDE beeng just slow or "beachbolling" may help.
Please use NEXT version 5.0 EAP (available on Aug 6) build to do all of this - the 4.0.x branch is significantly obsolete and we'll be unable to old shots to a good use.