Comment #83 on issue 164 by [email protected]: Wrong order in
Object properties interation
http://code.google.com/p/v8/issues/detail?id=164
Yes yes Tim, we all get your drift after all your comments that everyone
else is just being stupid about expecting browsers to retain same base
logic over time.
A lot of things have become standards after being implemented the same way
in different browsers and beople expecting them to keep working that way.
It's a shame that this has not been the same for to the Object element in
javascript, because right now the situation is, how to put it, kinda stupid.
There are lots of applications that depend on logically correct looping
(first added items get returned first, {20:'Some item 1',10:'Some item 2'})
because ALL browsers did it like that. Then came on the synthetic
benchmarks that drive the performance up and up and at some point someone
thinks, hey, this sort of ordering is not in spec, lets toss it out, and
gain a few more points on a synthetic benchmark.
Then we end up with a years long bug with people complaining about the
behaviour and bunch of people telling them to basically shut up, accept it,
all the while suggesting BAD workarounds that impact the performance
negatively (imagine that, performacne improvement for synthetic benchmarks
causes performance loss in real life examples :P).
Now, why are the proposed workarounds bad ?
One workaround is to prepend a non numeric character in front of the key
name (at server), so 1 turns to '_1' and later just, strip it away either
on the client side when building the select list (usual case for needing
ordering) or on server side after submit. It involves changing server side
logic on a lot of sites plus and possibly on client side also (even if you
can manage to send _1 to client and accept _1 back and convert to 1, then
when client side depends on SELECT tag having correct id values and is
doing dome lookups on page for that id, all such code needs changes too).
So put shortly, this involves a lots of works and creates lots of bug
conditions.
Second workaround (also suggested by tim) is to use arrays for that. Either
in form of [[2,'element 1'],[1,'element 2']] or [{2:'element
1'},{1:'element 2'}]. Now what's wrong with that ? Well, a lot to be
honest. When before you had the ID and wanted to get the value for it, you
just did var val = map[id]; With such structure you have to manually loop
the entire array, check if the id/key matches and then return the value.
var val = undefined; for(var i = 0; i < map.length; i++) if (map[i][0] ==
id) {val = map[1];break;}
Or for the case when using [{},{}] style then if part should be if (id in
map[i]) {val = map[i][id];break;}
And what's wrong with that ? Well, looping 1000 times in a 1000 item list
for example takes 1 000 000 iterations of checks, when instead letting the
internals do binary lookup or something like that would only sum up to 20
000 internal iterations perhaps. Plus it requires changes both on server
and client side to send out information in different structure and to
process it correctly also.
So, in conclusion: there is no viably fast workaround for getting previous
logic back. It's not fast or good to reimplement all the logic on server
side and on browser side. It is not possible to keep the correct id:value
association AND the original order without mangling the id value or losing
hugely in the performance of id lookups (you could argue that why not loop
the "special" map and create temporary copy that acts as real map and would
do faster lookups but again, issue of changing all the code, doing
unnecessary looping etc).
So, can someone explain to me again, how exactly throwing the ordering out
for synthetic benchmarks and thus changing the de facto behaviour to
something else is logical and performance wise for real life scenarios that
need ordering AND fast id based lookups on the same time???? And by the
way, it's recession time, making changes that involve globally hundreds of
thousands of hours of manpower is kinda resource-wasteful when people are
all trying to be most optimized and less resource-wasteful, wouldn't you
say :P
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
