> BTW, why do you think "make test" is a bad test of memory allocation
> patterns? What do you propose as a better test?
make test is synthetic. My primary use of smart_str involves
IRCG based application.
> That's very bad news, because actually my test show that about 95% of
> mallocs are for sizes below 100 bytes. But I hope the system malloc has
> some mechanism to deal with it, otherwise we are wasting a real lot of
> memory. Actually, given that tests show 90% of mallocs are for sizes below
> 64 bytes, if what you say is right, PHP's memory footprint is at least
> twice as big as it is meant to be.
Most applications use smart_str for temporarily creating some
representation, processing it quickly, and freeing it
immediately afterwards. I.e. the overhead in memory
allocation is not long term. IRCG is a good example here; it
can process GB of IRC data using a 6MB shared memory area.
Did you perform any benchmarks and if so, on which OS? Did
you try the same test with disabled memory cache?
> The number 80 was chosen because even if malloc allocates 128 bytes, these
> 128 bytes would be reused using the Zend memory cache. However, if the
> size of the segment does not allow it to be into the Zend memory cache,
> new malloc would be attempted each time. That was the primery rationale
> for the change, not the memory-saving argument, though it is important
> too.
Most malloc implementations are tuned for the repetitive
malloc/free pattern of the same size. For those, using the
engine's memory cache will not be an advantage, because it
prevents memory from being reused through ordinary malloc.
> BTW, the number 128 in the code allocated in fact at least 148 bytes, and
> I don't know what malloc implemetation would do of this.
That's pretty bad indeed.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
