How to copy multi object array contents into single object arrays?
in [JavaScript]
|
From: Lasse on 15 Jan 2010 05:03 On Jan 14, 7:17 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > In Firefox and Chrome it was more complicated. For array sizes of 10, 100, and > 1000 in Chrome, the backward was faster than forward by factors > approximately 1.5 - 2.5. But for 10000 elements, forward was faster > by a factor of about 1.25; I checked at 100000 elements too, and > forward was faster by a factor of about 1.5. The probable reason for this is that you start filling out the array from the back. This means that the array starts out with only one element af index 9999 - a very sparse array. Chrome and Firefox likely starts using an internal representation meant for sparse arrays, which is not as time efficient as linear arrays. If you fill out the result array from the start, it will always be densely packed, and will stay that way when the backing store is increased. Try changing your array initialization to var len = library.length, photos = new Array(len), captions = new Array(len); At least in Chrome this preallocates the array as a dense array with the given length. I also notice that the two algorithms differ in several ways. The backward one only reads library[i] once, whereas the forward one reads it twice. One uses foo.push(value), the other foo[i]=value. Both could use foo[i] =value. They also differ in how the the property is loaded: one uses foo.caption, the other foo["caption"]. That shouldn't matter, but there is no reason to make the tests look so different. Also, I don't see nearly as big a difference in Chrome 4 (dev-channel release, on Linux): Algorithm: Plain, elements: 1000000, elements per millisecond: 3817 Algorithm: Reverse, elements: 1000000, elements per millisecond: 4259 (using 5 iterations). /L
From: Thomas 'PointedEars' Lahn on 15 Jan 2010 06:11 Scott Sauyet wrote: > Jorge <jo...(a)jorgechamorro.com> wrote: >> Scott Sauyet <scott.sau...(a)gmail.com> wrote: >>> So, has anyone got suggestions for improving these tests? >> Yes, :-)http://jorgechamorro.com/cljs/093/ > > Thanks. I'm confused, though. You don't seem to assign anything to > "library". Am I missing somthing? If not, then the test seems to be > meaningless. ^^^^^^^^^^^ As always. >> BTW, It's not faster i-- than i++. > > No, I wouldn't expect it to be. But that doesn't imply that > > for (i = bound; i--;) {/* ... */} > > isn't faster than > > for (i = 0; i < bound; i++) {/* ... */} > > is, right? That's what Thomas was arguing. Exactly. It stands to reason that this applies simply because it takes one operation less. It would appear that setting array elements biases the result towards the incrementing loop because newer optimizations that consider sparse arrays come into play. var len = 100000; /* * WebKit throws a TypeError with this later; * base object of call must be `console' there */ var dmsg = typeof console != "undefined" && console.log || window.alert; var d = new Date(); for (var i = len; i--;) ; dmsg(new Date() - d); d = new Date(); for (var i = 0; i < len; i++) ; dmsg(new Date() - d); The second one is always considerably slower here (TraceMonkey 1.9.1.6, JScript 5.6.6626: > 100%; Opera 10.10: > 50%; JavaScriptCore 531.21.8: > 40%). PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: Jorge on 15 Jan 2010 07:12 On Jan 15, 12:11 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Scott Sauyet wrote: > > Jorge <jo...(a)jorgechamorro.com> wrote: > >> Scott Sauyet <scott.sau...(a)gmail.com> wrote: > >>> So, has anyone got suggestions for improving these tests? > >> Yes, :-)http://jorgechamorro.com/cljs/093/ > > > Thanks. I'm confused, though. You don't seem to assign anything to > > "library". Am I missing somthing? If not, then the test seems to be > > meaningless. Scott: learn to read code. > ^^^^^^^^^^^ > As always. Pointy: you're an IDIOT. The reality: var i= 1e6, a= [], d= +new Date(); while (i--) { a[i]= ""; } console.log(+new Date()- d); Safari4.0.4 --> 2012ms FF3.6 --> 1730ms ff3.5 --> 1674ms ff3.0.15 --> 1810ms Chrome --> 1114ms Opera 10.5b --> 665ms var len= 1e6, i= 0, a= [], d= +new Date(); while (i<len) { a[i++]= ""; } console.log(+new Date()- d); Safari4.0.4 --> 303ms 15% (!) FF3.6 --> 1110ms 64% ff3.5 --> 1236ms 73% ff3.0.15 --> 921ms 50% Chrome --> 1310ms 117% Opera 10.5b --> 680ms 102% -- Jorge.
From: Thomas 'PointedEars' Lahn on 15 Jan 2010 07:35 Jorge wrote: > Pointy: you're an IDIOT. Mirror, mirror ... > The reality: > > var i= 1e6, a= [], d= +new Date(); > while (i--) { a[i]= ""; } > console.log(+new Date()- d); Idiot. That's a *while* loop that *sets array elements*. Not a *for* loop that *does not*. PointedEars -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004)
From: Jorge on 15 Jan 2010 07:47
On Jan 15, 1:35 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Jorge wrote: > > > var i= 1e6, a= [], d= +new Date(); > > while (i--) { a[i]= ""; } > > console.log(+new Date()- d); > > Idiot. That's a *while* loop that *sets array elements*. Not a *for* loop > that *does not*. (load applause) *You* posted this code: for (var i = len; i--;) { var o = library[i]; photos[i] = o.img; captions[i] = o.caption; } And *you* said: "Benchmarks suggest it would be about 20% faster in TraceMonkey 1.9.1.6.". -- Jorge. |