144 (not 114!) bytes is for an integer; I'm not quite sure what the overheads are for arrays, which token_get_all() produces in abundance :) An empty array seems to occupy 312 bytes of memory.
Also, strings have memory allocated in 8 byte increments as far as I know, so "1" eats up 8 bytes, and "12345678901234567" will consume 24 bytes for the raw text, not 17. David On 07.06.2011, at 20:26, Mike van Riel wrote: > Am i then also correct to assume that the output of > memory_get_peak_usage is used for determining the memory_limit? > > Also: after correcting with your new information (zval = 114 bytes > instead of 68) I still have a rather large offset: > > 640952+2165950+114+(276697*114)+(276697*3*114)+2165950 = 131146798 = > 125M > > (not trying to be picky here; I just don't understand) > > _If_ my calculations are correct then a zval should be approx 216 bytes > (excluding string contents): > > ((244000000-640952-2165950-2165950) / 4) / 276697 = 215.9647B > > Mike > > On Tue, 2011-06-07 at 19:50 +0200, David Zülke wrote: >> memory_get_peak_usage() is the maximum amount of memory used by the VM of >> PHP (but not by some extensions for instance) up until the point where that >> function is called. So the actual memory usage may be even higher IIRC. But >> yeah, you're basically right. I've explained in another message why it might >> be so much more than you expected (zval overhead, basically) >> >> David > > >
smime.p7s
Description: S/MIME cryptographic signature
