[prev in list] [next in list] [prev in thread] [next in thread] 

List:       php-internals
Subject:    RE: [PHP-DEV] memory_get_usage with new Memory Manager
From:       "Andi Gutmans" <andi () zend ! com>
Date:       2006-07-29 3:26:01
Message-ID: 00cc01c6b2be$b965ba60$6600a8c0 () zend ! 2k
[Download RAW message or body]

Hi Matt,

Generally speaking enable-memory-limit is slower. That said, depending on
compiler & CPU architecture with small changes like this there could be some
different memory layout which affects CPU code caching and other low-level
CPU optimizations (branch prediction for example). It's possible that after
a small place in PHP (outside the memory manager) is changed, then it'd
suddenly be faster. What we need to stick to is what we know is true as to
how much code is being executed, and the incremental benchmarks we've done
over time on many of these smaller changes adding up to more significant
speed improvements.

As to what it really means. Let's just say it's significantly more accurate.
As we also ask for a relatively small amount of memory per block (256KB) we
will be at most off by 256KB as to real virtual memory commited.  That's
pretty good and long run it does allow for hosting providers and companies
to more accurately control the limits and Apache MaxClients by using this
setting. Also, using mmap() instead of growing the heap with brk() does
improve overall memory fragmentation and that's why you'll also see this
patch perform especially well under higher concurrencies and over time. With
the previous state it was more guess work and trial and error.
 
Again, if you really need to know how much memory you have allocated minus
the memory manager overhead, then we would probably add a slower function
which calculates that. That would be good for debugging, but seriously, for
runtime, it's far better for PHP to have a faster and more accurate way of
controlling memory size. I'm really not in favor of doing both bookeepings
in parallel because we really shouldn't add unnecessary code which could
impact runtime performance to one of the most called functions in PHP (if
not the most).

Cheers,

Andi

> -----Original Message-----
> From: Matt W [mailto:php_lists@realplain.com] 
> Sent: Friday, July 28, 2006 8:12 PM
> To: internals@lists.php.net; Andi Gutmans; 'Dmitry Stogov'
> Subject: Re: [PHP-DEV] memory_get_usage with new Memory Manager
> 
> Hi Andi, Dmitry,
> 
> Andi, yeah, I understand what you're saying... however, in my 
> tests on Windows at least, it was consistently faster *with* 
> --enable-memory-limit at the small sizes, which are used the 
> majority of the time, right?  I don't understand *how* it 
> was, with more variables being updated, things checked, but it was.
> 
> It's hard to explain what I mean, and it may not make sense 
> what I think about which memory usage to report (emalloc()'d 
> or real).  But I think like, "tell me how much memory *I've* 
> requested, regardless of what's happening 'under the hood.'"  
> (I think it's OK to check memory_limit against the real size, 
> though I wonder if some scripts will now be hitting the 
> memory limit when they weren't before.)
> 
> Here's what I really wanted to ask however...  IS the "real 
> size" actually being taken from the OS, or just the used 
> emalloc() size?  If you guys say it is, you're probably 
> right, since I don't know the details of how memory is 
> managed by the OS. :-)  But I found running my tests (again, 
> on Windows) that emalloc()'ing 1GB uses no more actual memory 
> than 512K (and only takes twice as long).  In other words, 
> even though the MM requested 1GB from the OS, it wasn't 
> actually "taken" since the space was never filled.  And I 
> assume if only 10K of that pointer was filled, only 10K would 
> be "taken"
> from the OS.  It looks like an optimization by Windows to 
> *not* give up memory until it's "actually used for real," 
> which makes sense.  Wouldn't other OS's do the same thing?  
> IF so (again, don't know), then the "real size" wouldn't 
> matter, would it?
> 
> 
> Matt
> 
> 
> ----- Original Message -----
> From: "Andi Gutmans"
> Sent: Friday, July 28, 2006
> 
> 
> > Matt,
> >
> > It's true that the difference might be minimal but we've 
> worked hard 
> > to improve the memory manager over the past couple of years 
> where many 
> > of
> these
> > improvements where minimal that added up.
> > I see no good reason to use this less accurate method of 
> checking how 
> > much memory is being consumed by the script for something 
> other than debug.
> > Therefore, I think the community is better served to make that
> functionality
> > a bit slower and having an always enabled, fast and 
> accurate memory limit.
> >
> > Andi
> 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[prev in list] [next in list] [prev in thread] [next in thread]