Andreas Junghans schrieb:
> Am 01.08.2006 um 23:12 schrieb Sebastian Werner:
>
>> Andreas Junghans schrieb:
>>> Am 01.08.2006 um 21:23 schrieb Sebastian Werner:
>>>
>>>> Andreas Junghans schrieb:
>>>>> Oh, and I think I missed a crucial point why your IE delete time is
>>>>> so high. It's probably not because of the garbage collector, but
>>>>> because the array gets reorganized on every delete (since an
>>>>> index is
>>>>> actually removed from it as opposed to simply assigning a new
>>>>> value).
>>>>> Looks like Firefox is way more efficient here ...
>>>> the delete doesn't shorten the array in my opinion.
>>> It doesn't change the "length" property of the array, but it does
>>> remove the index from the key collection (see "http://
>>> developer.mozilla.org/en/docs/
>>> Core_JavaScript_1.5_Reference:Operators:Special_Operators:delete_Oper
>>> ato
>>> r", last paragraph). After all, a JavaScript array is nothing more
>>> than a hash map with an additional "length" property. If you use
>>> "delete" on an index, the spec says that "index in myArray" should
>>> return false. To be able to do so, there has to be a collection of
>>> all the indices somewhere, and this collection is affected by the
>>> "delete" operator.
>> Ah. Cool. Thank you for the information. But this doesn't explain why
>> for some stuff arrays are faster. If arrays really are built up with
>> hash maps why are they faster for common array actions like loops?
>
> Because you can use simple counter loops ("for (i=0;i<x;i++)") to
> enumerate the keys (instead of "for (x in y)"). I think when you
> iterate over an array with for/in, you get the same performance as
> with any other object. I can't say whether there are some more
> internal optimizations for arrays, but at least semantically they
> behave like ordinary hash maps (with the exception of having an
> automatically updated "length" property whenever numeric keys are used).
But nobody really knows it, or is this explained in any reference.
Generally they could have a comparable API with completely different
implementations.
Mhh, I don't see why a counter should be faster than enumerate over the
keys. I there a reason to think it must be slower?
>
> Another example:
>
> x = new Array(1);
> x[0] = "Test";
> alert(x["0"]);
>
> This works just fine (showing an alert with "Test"), exactly like any
> other JS object/hash map where every key is converted to a string.
> And another one:
>
> x = new Array(1);
> x[0] = "Test";
> for (key in x) {
> alert(key + "/" + typeof key);
> }
>
> This displays "0/string", not "0/number". I'm not saying that there's
> really a string for every index (I hope this is optimized away, at
> least in Firefox ;-)), just that an array behaves like a hash map.
>
>> So a delete inside an array is maybe more comparable to a splice?
>
> Not quite. A splice has to re-assign many values to new keys, while
> delete only modifies the key space.
OK, you are right. But for the single value it's the same. Just ignore
my thoughts. ;)
Cheers,
Sebastian
>
> Regards,
>
> Andreas
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
