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

31–40 of 137 posts

Re: PHP 7's new hashtable implementation

#31

Post by stdbrouw »

Elv13 wrote: post #24
adunn wrote: post #22

Earlier quoted context omitted.

Well, yeah, I agree that the SPL types are nice to have. My complaint is that PHP's only first-class array type is a weird array/map combo. Have you ever seen anything like that in another language? The SPL types are definitely a welcome addition to the language, but they feel like add-ons. Definitely not first-class. The standard array functions don't work with SPL types (array_map, etc.) even though the SPL types a…

Lua also have hybrid array, maps and object. It does work well when implemented in a sane way. Lua has different way of iterating the table if you want an array or maps.

... though I wouldn't necessarily call Lua's way of doing things "sane". E.g. if Lua encounters a `nil` somewhere in your table, it will stop iterating.

Re: PHP 7's new hashtable implementation

#32

Post by juriansluiman »

aruggirello wrote: post #27
adunn wrote: post #7

This is great news. PHP doesn't have many structured data types, so arrays (aka maps) are basically used for everything. Any improvement to them will impact the entire application. It would be nice to have separate types for arrays and maps though. I don't understand why they were combined to begin with. Simplicity? Seems like there are more edge cases and gotchas the way things are now.

> arrays (aka maps) are basically used for everything. This is interesting. In fact, I believe object properties share the same mechanism as associative arrays, that is, $a->b will actually lookup the hash of "b" in $a. Does this new hashtable layout influence object properties/methods too? That would be huge!

> Does this new hashtable layout influence object properties/methods too?

Not sure, but I don't think so. Ppl often think object properties and arrays are much alike, but the array's HashTable struct and the object's store struct are very different. The main performance gains are not about the buckets (which are simple and quite alike) but the array's hashtable idea.

Often objects (php>=5.4) have a better performance than arrays; arrays have an undefined length while with good code, all object properties are defined at compile time. Because of this, you don't need to store the data in a hashtable. Nikic has a post about this subject too: https://gist.github.com/nikic/5015323

Re: PHP 7's new hashtable implementation

#33

Post by jakobegger »

imaginenore wrote: post #9
_RPM wrote: post #8

Earlier quoted context omitted.

> It would be nice to have separate types for arrays and hash tables though. I don't understand why they were combined to begin with. Simplicity? Seems like there are more edge cases and gotchas the way things are now. There is no "hash table" type in PHP user land.

There are no arrays in PHP. There are only hash tables that are called "array" for simplicity.

They aren't really hash tables either, because they additionally store the order of the keys (in a normal hash table, order would be arbitrary)

Re: PHP 7's new hashtable implementation

#34

Post by bzbarsky »

bhouston wrote: post #19

How does this compare to the optimized hashtable implementations in the various JavaScript runtimes? I imagine their requirements are similar?

First off, JavaScript runtimes (or at least V8 and SpiderMonkey, which are the ones I've looked at) don't convert their arrays to hashtables unless they really have to. If your array is not sparse and has no properties defined on it with non-integer names, then it's an actual array of values in memory.

Past that, even if you start defining non-integer names you still store the integer-named properties in a contiguous chunk of memory and store the named properties separately. This is why in V8 and SpiderMonkey the property order for an object (as seen by a for-in loop, say) doesn't match property addition order. Instead, the integer-named properties are enumerated first (in SpiderMonkey up to a certain limit) and then the other properties in addition order. So yes, the requirements are similar and JS engines throw some of them (property order preservation) under the bus to improve performance.

In SpiderMonkey, even once you have lots of properties (and are sparse and whatnot) and have converted to a hashtable, things are not that simple. The values are still stored in a contiguous memory buffer. There is a linked list of property descriptors which contain things like the property name and an index into the buffer, as well as metadata like whether the property is readonly and whatnot. This list is shared across objects that have the same property names added to them in the same order (though possibly with different values). What's stored in the hashtable, which can also be shared across objects is a mapping from property name to nodes in this linked list.

In practice, objects that have a dedicated hashtable just for that one object instead of sharing property descriptors with multiple other objects end up being pretty rare.

Lastly, JS engines are at least experimenting with unboxed storage for arrays. That is, instead of having a memory region filled with JS values, which might be of any type, detect at runtime that your array happens to only contain integers and have a memory region filled with integers; storing a non-integer will then cause a realloc and boxing of the data.

Re: PHP 7's new hashtable implementation

#35

Post by dsp1234 »

shimonamit wrote: post #29
brazzy wrote: post #25

Earlier quoted context omitted.

> My complaint is that PHP's only first-class array type is a weird array/map combo. Have you ever seen anything like that in another language? Um, Javascript?

Javascript's arrays cannot be used as maps or associative arrays. Arrays require numeric, consecutive keys. Otherwise it's an Object. -- Clarification edit: Creating a new key on an array using arr['key']=1 creates a property on the arr Object but does not add an element to the standard array. http://stackoverflow.com/questions/8630471/strings-as-keys-o...

Adding non-numeric keys does not remove an Array's "arrayness" in JavaScript

  var x = [];
  console.log(Object.prototype.toString.call(x));
  //[object Array]
  
  x[0] = 1;
  console.log(x[0]);
  //1
  
  x["test"] = 2;
  console.log(x["test"]);
  //2
  
  console.log(Object.prototype.toString.call(x));
  //[object Array]
  
  x.map
  //function map() { [native code] }

  var y = {};
  
  console.log(Object.prototype.toString.call(y));
  //[object Object]
  
  y.map
  //undefined

Re: PHP 7's new hashtable implementation

#36

Post by robocat »

shimonamit wrote: post #29
brazzy wrote: post #25

Earlier quoted context omitted.

> My complaint is that PHP's only first-class array type is a weird array/map combo. Have you ever seen anything like that in another language? Um, Javascript?

Javascript's arrays cannot be used as maps or associative arrays. Arrays require numeric, consecutive keys. Otherwise it's an Object. -- Clarification edit: Creating a new key on an array using arr['key']=1 creates a property on the arr Object but does not add an element to the standard array. http://stackoverflow.com/questions/8630471/strings-as-keys-o...

Arrays are full objects e.g. function(){ var x = []; x.foo = "bar"; return x.foo;} returns "bar".

That is the whole reason prototype.js library broke the use of for (var x in somearray) because the library set properties on Array.prototype.

Re: PHP 7's new hashtable implementation

#37

Post by joeyo »

stdbrouw wrote: post #31
Elv13 wrote: post #24

Earlier quoted context omitted.

Lua also have hybrid array, maps and object. It does work well when implemented in a sane way. Lua has different way of iterating the table if you want an array or maps.

... though I wouldn't necessarily call Lua's way of doing things "sane". E.g. if Lua encounters a `nil` somewhere in your table, it will stop iterating.

It's certainly sane in the sense that it was an intentional, if perhaps unusual, design decision. I personally like it since it results in an efficient implementation of sparse arrays.

In any event, Lua 5.2 will respect the __len, __pairs and __ipairs metamethods, so you can tweak this behavior if you need to store nils in your tables and iterate over them.

Re: PHP 7's new hashtable implementation

#38

Post by mmaunder »

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 to as efficient as it could and should be.

Re: PHP 7's new hashtable implementation

#39

Post by the_mitsuhiko »

dsp1234 wrote: post #35
shimonamit wrote: post #29

Earlier quoted context omitted.

Javascript's arrays cannot be used as maps or associative arrays. Arrays require numeric, consecutive keys. Otherwise it's an Object. -- Clarification edit: Creating a new key on an array using arr['key']=1 creates a property on the arr Object but does not add an element to the standard array. http://stackoverflow.com/questions/8630471/strings-as-keys-o...

Adding non-numeric keys does not remove an Array's "arrayness" in JavaScript var x = []; console.log(Object.prototype.toString.call(x)); //[object Array] x[0] = 1; console.log(x[0]); //1 x["test"] = 2; console.log(x["test"]); //2 console.log(Object.prototype.toString.call(x)); //[object Array] x.map //function map() { [native code] } var y = {}; console.log(Object.prototype.toString.call(y)); //[object Object] y.map…

It does internally. Pretty sure that's even defined in the standard.

Re: PHP 7's new hashtable implementation

#40

Post by Tegran »

Bahamut wrote: post #2

What happened to PHP 6?

If you do a Google search for "PHP6 Book" you'll see why they had to rename it:

https://www.google.com/#q=php6+book

Basically a lot of authors thought they'd get 'ahead of the game' and publish PHP6 books very early. If a 'real' PHP6 was released now, there would be confusion.

Post reply on HN