Comment #103 on issue 164 by [email protected]: Wrong order in
Object properties interation
http://code.google.com/p/v8/issues/detail?id=164
I created a simple page, that tests creation of object with different
styles, measures time and show how things used to work and how they work
now.
http://www.upload.ee/test/objtest.html
"They don't have the actual numbers on the speed boost for this." Well, if
they don't have any actual numbers comparing before/after then it's kinda
hard to just take their word for it, especially since none of them has
commented here with any information.
"This is because tracking order keeps the extra data in memory, which slows
down the app overall, even after iteration processes are done." Is this a
direct quote from the developer who is responsible for that code ? In
another bug thread there was sample of source code responsible for this
behaviour and basically all it did was something like that:
if (is_numeric(key)) return value_by_int_index(key);
else return value_by_string_hash(key);
Same sort of logic for get and set. So I would love to hear from an actual
Chrome developer why exactly does it take so much of an overhead to store
numerical keys in added/defined order but it's ok to keep that overhead for
pure string keys. When I tried {2:2} style where key was direct integer and
looped it later on, typeof key returned string, so internally all keys are
strings anyways...
And also, IE9 beta and Platform preview 7 finish that test page with 165ms
vs Chromes 235ms, and it also beated Chrome in such a test with platform
preview 2 or 3, whichever still retained the "loop as defined" order for
numeric keys also.
"So it's extra pain now but clears the way for better user experiences in
the future." How exactly is better user experience to create double load on
clients: first let the js engine parse the original json that is something
like [[12,'12']] and then loop through it and create object element for
lookup to be like {12:'12'}. All the memory usage concers go out of the
window, right there. You just doubled the size of data in memory. And more
likely [[12,'12']] takes more memory than {12:'12'}, even with "expensive
ordering data" and whatnot, because there is an array, which holds another
array, which has only 2 elements on it plus length counter (for every key
value pair there is length counter stored).
How come it is logical to try to preserve unnamed amount of memory and gain
unnamed amount of performance (which IE still did better even while keeping
the order) and ALSO logical to duplicate stuff in memory. Saving memory
just to use it up later on to gain same effect, just with much more work
involved....
As I stated before, all those "workarounds" come with memory and/or
performance impacts, which all invalidate the performance/memory gain
excuse/cause pointed out before. This sort of optimization only helps for
synthetic benchmarks, but for real life cases this behaviour just plain
sucks and does not gain anything except extra work for developers who need
id => value mapping to retain the order.
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
