| Previous | Next |
| STATUS_NOT_SAME_OBJECT | STATUS_ERROR_PROCESS_NOT_IN_JOB |
STATUS_FATAL_MEMORY_EXHAUSTION
You should never try to allocate the total available memory to your runtime - this becomes more and more true the higher level your language is.
Even with very low level languages (which PHP is not, of course), you'll need not just the memory for the bytes that you're allocating (which will be going into heap space), but the memory for the instructions and call stack.
As you get into higher level and interpreted languages, that overhead only increases - the interpreter is going to need its own amount of memory, and there may not be any good or reliable way (whether across versions or even across configurations of the same version or executions within the same configuration) to determine exactly how much "padding" that environment/runtime will need.
In your case, you already suspect that you may come close - you should pick a "safe" amount of buffer space to leave for the runtime, for instance, if you know you're going to try to allocate more than 90% of the available memory to the runtime you shouldn't (and for a language like PHP, where you're very likely running in an server environment where other consumers are competing for the same resources, that threshold should likely be much lower).
In general, it's good practice to avoid consuming more memory than necessary, especially in interpreted and web-based environments. While memory trade-offs might be worth it to shorten execution time (particularly when loading more data in memory will save you time on lots of repeated calculations that would take longer to repeatedly allocate memory for and then deallocate memory for only to reallocate it), the case you're talking about here doesn't really make sense for that. This is the reason that you'd prefer a streaming model, where you only allocate as little memory as necessary to read the part of the file you can reasonably serve (as opposed to a situation where you have to repeatedly process different parts of that file, and then reprocess certain parts of them based on what you just processed - e.g. a routine that has to backtrack frequently in the file to know what to do next).