Since nobody else has chimed in with the obvious (to me, anyways):
I've worked with some code that uses disgustingly huge (>512Mb) arrays,
largest implementation was a single 2.5 Gb array (before we took the
offending programmer into a room and had a... chat).
I'd be interested in seeing so
On Nov 10, 2008, at 5:24 PM, shire wrote:
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?).
My point is, replaci
On Nov 10, 2008, at 4:28 PM, Stan Vassilev | FM wrote:
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 ;-) ).
Yes I'm talking about speeding up scenarios full of hash lookups in
general.
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 ;-) ).
Yes I'm talking about speeding up scenarios full of hash lookups in general.
It sounds like this would only work if the array contents
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 application
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
On Nov 6, 2008, at 10:37 AM, shire wrote:
However, while the common compare_function call probably wouldent
gain anything from this, maybe it could be put in the
TYPE_PAIR(IS_STRING, IS_STRING) case or put into zendi_smart_strcmp
(which only seems to ever be called by the TYPE_PAIR(IS_ST
Hi,
I'd completely agree with that patch - it's very useful for me since I only
build applications based on arrays;
I'll try to apply some other modifications - and maybe we got it ;-D
- benchmarking the app core-
Your,
--
(c) Kenan Sulayman
Freelance Designer and Programmer
Life's Live Poetry
On Nov 5, 2008, at 7:22 AM, Graham Kelly wrote:
Hi,
I played with a patched version of compare_function with this
optimization in it. Other then for strings it didn't seem to make
much of a difference. A quick test showed that in an average php
application only about 0.15% of calls to co
Hi,
I played with a patched version of compare_function with this optimization
in it. Other then for strings it didn't seem to make much of a difference. A
quick test showed that in an average php application only about 0.15% of
calls to compare_function actually have the same op1 and op2. Conside
Hello again,
once again top posting this this is fairly old ..
however for something that is sounding so promising I am wondering why
this hasnt been picked up ..
regards,
Lukas
On 20.10.2008, at 22:09, shire wrote:
On Oct 19, 2008, at 12:11 PM, Karoly Negyesi wrote:
Hi,
I think zend_h
On Oct 19, 2008, at 12:11 PM, Karoly Negyesi wrote:
Hi,
I think zend_hash_compare could get a healthy speed boost in some
cases if first it would check whether the two variables passed to it
are actually the same (because of "reference counting"). Sorry, my C
skills are way too rusty to write
12 matches
Mail list logo
