On Nov 10, 2008, at 2:32 PM, Stan Vassilev | FM wrote:

I just ran a quick benchmark on this and I'm not seeing a significant real world change for Facebook's codebase. (definitely less than 1%) This was a pretty small test, without a lot of code execution, so I could see other applications doing better. I'm pretty neutral on this one, it's not a really big change so might be worth adding if it's going to give a few applications out there a gain, but I couldn't see doing this everywhere of course.

-shire


Hi,

Something that could give arrays a boost would be to:

- pool all string literals in each file
- give each stringl iteral an id (unique in the loaded environment)
- bind early all array access with string literals (a common occurence), so they don't need to be resolved with a hashmap lookup, but rather, a direct stirng literal id lookup.

The benefit of this approach are:

- There's no need to generate a hashmap in the first place
- String literal id-s are unique integers and have no conflicts, so no need to do conflict resolution.



This wouldn't really help with the case here of "if ($array1 == $array2)..." though right? (not to say it's not good, just making sure I understand ;-) ).

It sounds like this would only work if the array contents where static though, as you're mapping a constant string to the contents of the hash (or did I misunderstand and you'd be mapping string const. values to hash IDs?).

I am at the point now where my #1 item CPU wise is my hash function. I'm working on finding a slightly faster implementation, but I'm also playing with having a hash value stored in every zval so that the hash function call can be skipped if we've already ran it once. The problem that comes into play here is that there's no central code to update or clear the hash if the string or contents of the zval change. Of course, doing this with constant values would be easier to accomplish and could be done at compile time, and like you say this is a pretty common scenario.

-shire

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

Reply via email to