I know that this is an old issue, but I need some help as even just a single file loaded into a fresh restart of the IDE will eventually popup this message. I have downloaded v19 onto several test systems to try and find a system which wont pop this error up, but its happening on all of them.

Ive tried to find a system where it wont happen, but all computers, some new keep getting this issue. I have systems with 8, 12 and 20 GB RAM installed. I was hoping the most recent version would have addressed it specifically, but it seems to be the same experience.

Is there any new information on what to do with this issue? Its really getting in the way, and Im hoping there is a simple solution to it. I have noticed that when all the web browsers are shut down, it goes for a very long time before happening, but that doesnt really help.

QUESTION: Is there anyway to simply stop a low virtual memory test? It seems arbitrary, and the computer handles all the memory anyway.


I really enjoy using PHPEd, but Ive got to get passed this issue.

It depends on type of the product you're using. We ship two versions -- 32bit and 64bit. If it is 32bit version, process can access to ~ 3GB of virtual space only. While 32bit means 4GB, 1GB is excluded because it's reserved for window kernel address space. It's not necessarily a bug in the product as any dll injected into the process can allocate memory and eventually take it all. For this case my suggestion would be a) check if you can run 64bit version of the product - in the first place and b) check what application and / or subsystem is responsible for memory consumption. In order to do that you need fresh system with no 3rd party software installed at all, including (but not limited) graphics card, network card, antivirus, firewall, etc. Everything that came not from MS, should be excluded. If the problem is gone in clean system, try to install 3rd party products one by one and check. It's easier to do so in VMware, where you can set checkpoint and rollback to it to re-check.

In 64bit case, PhpED does not monitor system memory so closely.

There is also one limit that stems from the code insight db -- those <projectname>.ppx files. Its size is limited to 2GB. It's enough for quite large projects like magento based. But if you have many many js files, like original files, backup copies, minified versions etc etc etc, this 2GB space may not be enough. I'd recommend you to check what directories in your project have such copies and exclude them by adding corresponding directory names to the hide list in project properties.

In short, it does not matter how many files you open. It matters what project you have, what type of product you run and what other applications you have installed.

Thank you for the response. Its appreciated as I can experiment with a few things to hopefully push back on this memory issue. I am running with 64bit, so that is good, but there are also anti-virus programs and other security related solutions which have caused problems in the past. Good tip on the javascript/ppx as well. I will check into these areas.

Hello Dmitri,

Everything you mentioned says the system should be fine. I am running a system with very little running relative to modern standards. It has 16GB of memory, and is a modern gaming system. The ppx files are 110 MB and smaller.

Something is triggering this message, and as soon as that happens, everything that makes the IDE great shuts down immediately (live context searching).

The project is not a large one, but has many folders (perhaps a thousand) because of the nature of how the system operates. Is there anything about how the project layout (such as backup folders) which could be causing this? For example, I have this "_backup_2020-10-15_153812" type of folder name just to keep a copy near by of working PHP code.

110MB ppx should be ok, but it does not mean that run-time version of ppx is of the same size. Indeed, the IDE operates with a copy of ppx. If it successfully finished, when you quit or switched to another workspace, run-time copy will be returned back to original ppx. Low virtual memory is not a successful finish and most likely it lost run-time copy and therefore you don't know what size it got. If parser keeps running for a while, I believe ppx is accumulated way more than 110MB. My suggestions in previous post still stand.