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 possibl
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,
I would like to submit a replacement for the Win32 mssql extension that I have
recently completed. The extension provides the same set of functions as mssql,
but uses OLEDB to talk to SQLServer instead of DBLIB. It allows users to
retrieve varchar column wider than 255 and also Unicode columns a
> -Original Message-
> From: Pierre [mailto:[EMAIL PROTECTED]
> Sent: 28 July 2006 18:34
> To: [EMAIL PROTECTED]
> Cc: Kevin Waterson; internals@lists.php.net
> Subject: Re: [PHP-DEV] testing filter ext in RC1
>
> On 7/28/06, Jared Williams <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> >
Hi,
An empty string returns 0.
php -r "$var=''; var_dump(filter_data($var, FILTER_VALIDATE_INT));"
int(0)
Which maybe is what was intended, but imho still should return false.
Jared
> -Original Message-
> From: Pierre [mailto:[EMAIL PROTECTED]
> Sent: 28 July 2006 17:44
> To:
He was ranting on IRC about Israel bombing a UN post in Lebanon. He
used to do the same job for UN, by the way.
From #php.pecl:
Jul 27 17:16:21 <_sniper_> I will also quit this project. As long as
it's backed by some Israel company, I don't want to have anything to
do with it.
-Andrei
On 7/28/06, Jared Williams <[EMAIL PROTECTED]> wrote:
Hi,
Also it does seem NUL char safe?
php -r "$var='3'.chr(0).'foo'; var_dump(filter_data($var,
FILTER_VALIDATE_INT));"
int(3)
Please report bugs in pecl.php.net/filter. It is hard to keep a trace
of each post around here :)
Thanks
Did I miss something?
--
Matt Sicker
pgp3FM89DTG8E.pgp
Description: PGP signature
On 7/28/06, Kevin Waterson <[EMAIL PROTECTED]> wrote:
This one time, at band camp, Pierre <[EMAIL PROTECTED]> wrote:
> > if var was abc1234 then it would return NULL, is that correct?
>
> False if the value is not valid, null if the value does not exist (for
> example with input_get or input_ge
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 b
This one time, at band camp, Pierre <[EMAIL PROTECTED]> wrote:
> > if var was abc1234 then it would return NULL, is that correct?
>
> False if the value is not valid, null if the value does not exist (for
> example with input_get or input_get_args). In the case of filter_data,
> as you pass the
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
They work only with --enable-memory-limit.
Dmitry.
> -Original Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 28, 2006 11:20 AM
> To: Dmitry Stogov
> Cc: 'Andi Gutmans'; 'Ilia Alshanetsky'; 'Ron Korving';
> internals@lists.php.net
> Subject: RE: [PHP-DEV]
Hi Matt,
In case of small size (size <= 128B), your code fit into special case, those
handled by allocator's cache.
The memory_usage information isn't updated in this case.
128B < size < 256KB - uses zend memeory manager and updates memory_usage
information.
Seems it works with the same speed.
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
Hi,
More thoughts...
I forgot to say last time that the manual doesn't mention the dec*()
parameter being treated as unsigned. The *printf() specifiers b/o/x/X
already do this (although the manual doesn't say that either, only for %u).
After looking through the comments for dechex(), there's an
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
21 matches
Mail list logo
