Re: [PHP-DEV] zend_hash_add_or_update flaw From: Andi Gutmans (andi <email protected>)
Date: 12/06/00

By the way, I just checked the glibc assembly routine and it seems to be
quite a bit slower. The i686 version is like 20 assembly commands and it
looks as if it's implemented as a function (unless gcc takes care of it
earlier).
Anyway, I don't think there's a nice way around it but it's a bit annoying
that we need to convert to memcpy().
Maybe if the third parameter of memcpy() is a constant some compilers will
detect and optimize it? I do remember on some systems memcpy() being a
compiler internal function and according to its nature the compiler either
calls a C function or create the assembly itself.
So we would keep it as memcpy(dst, src, sizeof(void *));
I don't really care about not using pDataPtr for smaller than void * data.
The second we put nDataSize as the third parameter we can say bye bye to
any compiler optimization. This is of course, if we actually know (and I
don't) if some compilers would optimize this.

Andi

At 09:50 PM 12/6/00 +0100, Sascha Schumann wrote:
> > Right. It doesn't work with unaligned data but did you actually bump into
> > such a case in PHP? I prefer not moving to memcpy() unless this is actually
> > the case.
>
> Yes (please refer to my first message). We are basically
> strtok'ing through a string and adding parts of that string
> to the hash.
>
> memcpy is often implemented as an inline function or even
> assembler by the C library, so the speed impact should be
> negligible.
>
> - Sascha 

---
Andi Gutmans <andi <email protected>>
http://www.zend.com/

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
For additional commands, e-mail: php-dev-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>