Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP 7's new hashtable implementation

nikic.github.io

Post reply on HN
Print view View original

131–137 of 137 posts

Re: PHP 7's new hashtable implementation

#131

Post by gburt »

mmaunder wrote: post #38

Awesome, but I still don't think it's enough. In benchmarks we did the memory usage of PHP array() was horrific. Sorry I don't have actual numbers to post, but we ended up using pack() and unpack() to store stuff that should have been in an array because it would grow to 100's of megs using PHP's array() and using a binary structure it stays under 10 megs. I just don't think a 2.5X improvement is going to come close…

This is my experience benchmarking the same as well. That, combined with a bug in SPLFixedArray that results in it acting like a non-fixed array past some size, makes it very difficult to consider PHP for anything that requires high performance on tight loops/data crunching.

To the extent that it is often viable to run another programming language's implementation of your code operating as a service for your PHP code.

Re: PHP 7's new hashtable implementation

#132

Post by Arnavion »

gsnedders wrote: post #124
Arnavion wrote: post #112

Earlier quoted context omitted.

By the way, JS runtimes used to have insertion order for enumerating properties long before the hidden class optimization or V8 was a thing. V8 was the first to break the insertion-order enumeration for some kinds of objects [1] and eventually other browsers followed suit, even those that don't do hidden classes. [1] http://code.google.com/p/v8/issues/detail?id=164

Who doesn't do "hidden classes" (or maps, or inferred-classes, or whatever else we're calling them today)? All major JS engines certainly do.

My point was that hidden classes is not a reason to keep nor break insertion-order enumeration. The example I gave was V8 breaking insertion-order enumeration, but for a reason entirely unrelated to its use of hidden classes - it implements Arrays as Objects with consecutive numeric keys, so Objects with consecutive numeric keys get enumerated like Arrays.

So yes, while all major browsers use hidden classes today, that itself is not sufficient to explain why insertion-order enumeration is not maintained.

Re: PHP 7's new hashtable implementation

#133

Post by allendoerfer »

username223 wrote: post #127
allendoerfer wrote: post #23

It is both nice and concerning, that an ubiquitous element of a ubiquitous language has that much potential for performance optimizations after 19 years of development. The optimizations were not even complicated hacks for edge cases, just a simpler implementation overall. But then again, PHP itself being stateless between requests is quite fast already, nice to see even more performance getting squeezed out. Imagine…

> a ubiquitous language has that much potential for performance optimizations after 19 years of development. "Code in haste, repent at leisure." PHP was designed with some unholy amalgam of an array and a hash table as its only data structure, so there's plenty of room for repentance. It makes me feel old to remember learning about (singly-) linked lists, arrays, and hash tables, plus some other nice things, in a fre…

You are right. That PHP actually runs is a small wonder. They actually rewrote the engine every few years.

When i was in college and visited said lecture, I was quite surprised, what an array actually is. But on the other hand, if it had not been for PHP and its small step from HTML, I imagine many young programmers like me would know neither the false nor the right array.

Re: PHP 7's new hashtable implementation

#134

Post by overgard »

gburt wrote: post #130
overgard wrote: post #110

Earlier quoted context omitted.

Wow, I constantly think that nothing about the horribleness of PHP can surprise me, and then Rasmus says something even more insane than his already insane statements. I mean choosing function names based on length because you didn't bother to write an actual hash function? AMAZING. Anyway I'm just going to leave this here because it's great fun: http://en.wikiquote.org/wiki/Rasmus_Lerdorf Some favorites: "There are…

To be fair, his "get things done" attitude is a big part of why PHP is so popular. It avoids all pedantry and nerdiness (even when it absolutely shouldn't), erring entirely on the side of "let's just get something working." That might not be the right attitude for all programming languages, but it is working for PHP in at least some sense.

I will admit that's a fair point. The one virtue PHP has is that it's pretty direct in what it does.

Re: PHP 7's new hashtable implementation

#135

Post by porker »

porker wrote: post #42
mmaunder wrote: post #38

Awesome, but I still don't think it's enough. In benchmarks we did the memory usage of PHP array() was horrific. Sorry I don't have actual numbers to post, but we ended up using pack() and unpack() to store stuff that should have been in an array because it would grow to 100's of megs using PHP's array() and using a binary structure it stays under 10 megs. I just don't think a 2.5X improvement is going to come close…

> we ended up using pack() and unpack() to store stuff that should have been in an array because it would grow to 100's of megs using PHP's array() and using a binary structure it stays under 10 megs. How many items were you storing / how big was the data in each item?

To whoever downvoted this comment, please say why.

Re: PHP 7's new hashtable implementation

#136

Post by locusm »

smsm42 wrote: post #109
debacle wrote: post #101

Earlier quoted context omitted.

I'm not sure if you know how to read: dev@aerilon ~/dev $ hhvm memusage.php 2 MBs [2097152 bytes] That is using the same benchmark that nikic is using, and it's using half the RAM of her PHP 7 example . Please try and be less apologistic and use some reading comprehension. It makes you look more intelligent and puts less stress on other people to accommodate your intellectual laziness.

There's no such word as "apologistic" (really, look in the worduary, which should be available in your local bookery). And the result shows PHP 7 reduced memory usage by hashtables threefold since 5.5. Yes, this is pretty good. No reason to be bitter or sarcastic.

LOL My 11 & 8 yr old thought that was pretty funny too...

Re: PHP 7's new hashtable implementation

#137

Post by scottlamb »

nikic wrote: post #98
nly wrote: post #85

An important variable determining memory consumption is going to be the maximum bucket load factor. Does anyone know what it is as currently implemented?

The maximum load factor is 1. A lower load factor only makes sense if open addressing is used.

> The maximum load factor is 1. A lower load factor only makes sense if open addressing is used.

I don't think that's quite true for their data structure. Consider a full hash table which is repeatedly used like a queue (first element removed; another added). (I'd bet some PHP code out there is doing this.)

"The arHash array has the same size (nTableSize) as arData and both are actually allocated as one chunk of memory." As arData (and thus the arHash) becomes full, the arHash IS_UNDEF optimization becomes useless. Every insertion is O(n) because every element has to be moved up one. On the other hand, if there were 2n slots, all 2n would have to be touched only once every 2n insertions, which means insertion requires amortized constant time.

On the other hand, that'd perhaps cause there to be n-1 IS_UNDEF values at the beginning, so iteration could be problematic. They could do various things to avoid long runs of IS_UNDEF, but given that they could occur anywhere in the hash (not just at the beginning), I think the best might be to use an unrolled linked list as well. Then they could bound the number of consecutive IS_UNDEF values while still getting much of the benefit of fewer pointers and better locality. They could still put all the nodes in one allocation if they were so inclined; there would just be some extra pointers and not strictly linear iteration.

Post reply on HN