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
