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:[EMAIL PROTECTED]
> Sent: Friday, July 28, 2006 8:12 PM
> To: internals@lists.php.net; Andi Gutmans; 'Dmitry Stogov
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,
nt: Friday, July 28, 2006 4:08 AM
> To: internals@lists.php.net; Dmitry Stogov; 'Andi Gutmans'
> Subject: Re: [PHP-DEV] memory_get_usage with new Memory Manager
>
> Hi Dmitry,
>
> No, there's always more work going on (with
> --enable-memory-limit) with every e
Hi Dmitry,
No, there's always more work going on (with --enable-memory-limit) with
every emalloc() call to update the size even when real_size isn't updated,
right? Meaning
heap->size += true_size;
if (heap->peak < heap->size) {
heap->peak = heap->size;
}
at the end of _zend_mm_alloc_int
On Fri, 28 Jul 2006, Dmitry Stogov wrote:
> They work only with --enable-memory-limit.
Which is perfectly fine if you ask me :) But I get it now then.
regards,
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
internals@lists.php.net
> Subject: RE: [PHP-DEV] memory_get_usage with new Memory Manager
>
>
> On Fri, 28 Jul 2006, Dmitry Stogov wrote:
>
> > Good idea, but it allows only memory_get_usage() and not
> > memory_get_peek_usage() :(
>
> But both of those both
di Gutmans
> Subject: Re: [PHP-DEV] memory_get_usage with new Memory Manager
>
>
> Hi all,
>
> For my own curiosity regarding the overhead with memory-limit
> or keeping track of usage so memory_get_[peak_]usage() can
> always be enabled, I just did some quick testing. Using
Hi all,
For my own curiosity regarding the overhead with memory-limit or keeping
track of usage so memory_get_[peak_]usage() can always be enabled, I just
did some quick testing. Using this code
PHP_FUNCTION(emalloc_tester)
{
int i;
long mem_size;
void *ptr;
if (zend_parse_param
Hi Richard,
Andi probably stole the idea. ;-P
No, I had kinda wondered the same thing... Not about counting memory only
when requested, but if there was a fairly quick/simple way for the slack
space to be calculated (to get the emalloc()'d size from the real size)
without having another variable
That's what I said (more or less)! Have you all got filters on me?
On 28/07/06, Andi Gutmans <[EMAIL PROTECTED]> wrote:
I personally think that we should keep the more accurate behavior both
because it's the most accurate and what most people would expect when
setting memory limits, and because
Hi Derick,
He's referring to Andi's suggestion of having a slow function calculate mem
usage only when requested. Wouldn't work for peak, of course.
Matt
- Original Message -
From: "Derick Rethans"
Sent: Friday, July 28, 2006
> On Fri, 28 Jul 2006, Dmitry Stogov wrote:
>
> > Good ide
On Fri, 28 Jul 2006, Dmitry Stogov wrote:
> Good idea, but it allows only memory_get_usage() and not
> memory_get_peek_usage() :(
But both of those both work now? So I am not seeing the problem...
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
PHP Inte
ng much
> better and more efficiently.
>
> Thoughts?
> Andi
>
> > -Original Message-
> > From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] On Behalf Of
> > Ilia Alshanetsky
> > Sent: Thursday, July 27, 2006 10:33 AM
> > To: Ron Korving
> > Cc: in
Ilia Alshanetsky wrote:
On 27-Jul-06, at 9:03 AM, bertrand Gugger wrote:
That may hear off topic , but how you enable something else than 8M
*without* getting this counting overhead ?
Eh? When you set a limit what are you trying to do? From my experience
most of the time this setting i
ky
> Sent: Thursday, July 27, 2006 10:33 AM
> To: Ron Korving
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] memory_get_usage with new Memory Manager
>
>
> On 27-Jul-06, at 1:17 PM, Ron Korving wrote:
>
> > Yes, hosting providers would enable the memory limit. But
On 27-Jul-06, at 1:17 PM, Ron Korving wrote:
Yes, hosting providers would enable the memory limit. But who wants
to use
memory_get_[peak_]usage()? Not the hosting provider, but the
application
developer.
The peak usage function was added with profiling in mind and keeping
track of scri
Yes, hosting providers would enable the memory limit. But who wants to use
memory_get_[peak_]usage()? Not the hosting provider, but the application
developer.
We have some process, that if cache has gotten stale and needs to be
recreated, the process can use 100MB or memory. We don't want to c
Hi Ilia,
"Ilia Alshanetsky" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Eh? When you set a limit what are you trying to do? From my
> experience most of the time this setting is used by hosting providers
> to restrict memory utilization of various PHP scripts to avoid out-of-
> m
Hi Dmitry,
Thanks for the reply. :-)
To the others mentioning the overhead and "slowness" of keeping track of the
memory size, I can't believe that, relative to ALL the other work being done
in emalloc()? I was going to try a loop of emalloc() and efree() with and
without memory-limit just to se
On 27-Jul-06, at 9:03 AM, bertrand Gugger wrote:
Ilia Alshanetsky wrote:
On 27-Jul-06, at 6:02 AM, Matt W wrote:
Something else I'd like to see changed... Does anyone think
memory_get_[peak_]usage() should *always* be available,
regardless of
whether memory_limit is actually enabled? Usi
Ilia Alshanetsky wrote:
On 27-Jul-06, at 6:02 AM, Matt W wrote:
Something else I'd like to see changed... Does anyone think
memory_get_[peak_]usage() should *always* be available, regardless of
whether memory_limit is actually enabled? Using the Windows binaries at
least, I was devastated
On 27-Jul-06, at 8:50 AM, Dmitry Stogov wrote:
Now, functions memory_get_[peak_]usage() and memory_limit checking
can be
enabled/disabled using "--enable-memory-limit" configure option.
However
cost of meory_limit checking is significant less with new memory
manager.
I'd prefer to avoid
I'm NOT a expert in this field. My POV may be quite dumb, but it may
point to a solution.
If memory is allocated, I would assume that somewhere there is a
mechanism to access it otherwise this is a memory leak.
So, rather than counting the memory in real time, why not have the
memory_get_usage()
ll return "real" memory usage.
What do you think?
Dmitry.
-Original Message-
From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] On Behalf Of Ilia
Alshanetsky
Sent: Thursday, July 27, 2006 4:35 PM
To: Matt W
Cc: internals@lists.php.net; Dmitry Stogov
Subject: Re: [PHP-DEV] memory_get_u
On 27-Jul-06, at 6:02 AM, Matt W wrote:
Something else I'd like to see changed... Does anyone think
memory_get_[peak_]usage() should *always* be available, regardless of
whether memory_limit is actually enabled? Using the Windows
binaries at
least, I was devastated :-D that they were unavai
Matt W wrote:
> Hi Dmitry, Ilia, et al.,
>
> Ilia, the Memory Manager is checking the *real* size against memory_limit,
> so it's still "more accurate" even after the functions were changed to
> report more like the old way. I still wonder how much difference there may
> be between size and real_s
Hi Dmitry, Ilia, et al.,
Ilia, the Memory Manager is checking the *real* size against memory_limit,
so it's still "more accurate" even after the functions were changed to
report more like the old way. I still wonder how much difference there may
be between size and real_size as it gets close to t
The idea of a memory limit is to as accurately as possible account
for the memory utilized by PHP. If our current calculation is more
accurate since it accounts for malloc overhead, great, it gives more
fine grained control to hosters utilizing this option.
On 25-Jul-06, at 9:45 AM, Lukas
On 25.07.2006 16:45, Lukas Smith wrote:
Dmitry Stogov wrote:
Right now memory_get[peak_]usage() show the amount of REAL memory that PHP
(Zend Memory Manager) takes from system.
Previous memory manager showed size of emalloc()-ed memory without malloc()
overhead.
Also it didn't consider internal
Dmitry Stogov wrote:
Right now memory_get[peak_]usage() show the amount of REAL memory that PHP
(Zend Memory Manager) takes from system.
Previous memory manager showed size of emalloc()-ed memory without malloc()
overhead.
Also it didn't consider internal caches.
Shouldn't we make the old beha
On 25-Jul-06, at 7:24 AM, Dmitry Stogov wrote:
Good suggestion.
The correspomding C functions (zend_memory_usage()) can be changed
in the
same way.
The memory_limit will de checked for real usage only (as now).
Any objections?
Nope, sounds good to me.
Ilia Alshanetsky
On 24-Jul-06, at 11:52 PM, Matt W wrote:
Does anybody else think that memory_get[peak_]usage() should work
more like
before? I would imagine it can be "fixed" fairly easily, though it
probably
needs another variable, and just a little extra overhead of inc./
dec. that
variable more often (b
Hi,
That's what I was thinking too, Ron. Internally, the functions
zend_memory_[peak_]usage() would also get a flag parameter, or separate
functions...
There's also the small issue of which size to set Apache's mod_php_mem_usage
to.
Dmitry, et al., I don't know the details of how the Memory Man
25, 2006 2:21 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] memory_get_usage with new Memory Manager
>
>
> Perhaps it'd be a nice alternative to have an optional
> parameter? Having 4
> functions for checking memory usage is quite a lot, isn't it?
>
ndi Gutmans'; 'Ilia
> Alshanetsky'
> Subject: RE: [PHP-DEV] memory_get_usage with new Memory Manager
>
>
> On Tue, 25 Jul 2006, Dmitry Stogov wrote:
>
> > > > Right now memory_get[peak_]usage() show the amount of
> REAL memory
> > > > that PHP
Perhaps it'd be a nice alternative to have an optional parameter? Having 4
functions for checking memory usage is quite a lot, isn't it?
I would humbly prefer seeing:
int memory_get_usage([bool realusage])
int memory_get_peak_usage([bool realusage])
- Ron
"Derick Rethans" <[EMAIL PROTECTED]>
On Tue, 25 Jul 2006, Dmitry Stogov wrote:
> > > Right now memory_get[peak_]usage() show the amount of REAL memory
> > > that PHP (Zend Memory Manager) takes from system.
> > >
> > > Previous memory manager showed size of emalloc()-ed memory without
> > > malloc() overhead. Also it didn't consid
> -Original Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 25, 2006 10:58 AM
> To: Dmitry Stogov
> Cc: 'Matt W'; internals@lists.php.net; Andi Gutmans; Ilia Alshanetsky
> Subject: RE: [PHP-DEV] memory_get_usage with new Memor
memory_get_real_[peak_]usage() ? :)
--Jani
On Tue, 25 Jul 2006, Derick Rethans wrote:
On Tue, 25 Jul 2006, Dmitry Stogov wrote:
Right now memory_get[peak_]usage() show the amount of REAL memory that PHP
(Zend Memory Manager) takes from system.
Previous memory manager showed size of
On Tue, 25 Jul 2006, Dmitry Stogov wrote:
> Right now memory_get[peak_]usage() show the amount of REAL memory that PHP
> (Zend Memory Manager) takes from system.
>
> Previous memory manager showed size of emalloc()-ed memory without malloc()
> overhead.
> Also it didn't consider internal caches.
5.2.0 release.
Thanks. Dmitry.
> -Original Message-
> From: Matt W [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 25, 2006 7:53 AM
> To: internals@lists.php.net
> Subject: [PHP-DEV] memory_get_usage with new Memory Manager
>
>
> Hi,
>
> After looking thr
Hi,
After looking through the new Memory Manager code, I assumed this would be
the case... (and just now got to test). Since heap->size is only updated
when a 256K or whatever block is *actually* allocated/freed, the number
returned by memory_get_usage() will only be a multiple of that. That
doe
42 matches
Mail list logo
