How to copy multi object array contents into single object arrays?

G

Garrett Smith

Thomas said:
Garrett said:
var imgArray = library.map(filterByName("img"));
var captionArray = library.map(filterByName("caption"));
[...]

Where not supported, Array.prototype.map functionality can be added, as
indicated on MDC page[1].

What a waste. If an Array prototype method should be used here, then
Array.prototype.forEach().

Array.prototype.forEach calls a supplied function on each element in the
Array. It does not create a new Array.

Array.prototype.map creates a new array with the results of calling a
supplied function on each element in the array.

And yes, much more efficient to just loop it yourself.
 
G

Garrett Smith

Lasse said:
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.

Did you notice the test code + results I posted?
Message ID: [email protected]
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);

The Array constructor is a little bit slower from the solution I provided:
var len = library.length, photos = [], captions = [];
photos.length = captions.length = len;
 
T

Thomas 'PointedEars' Lahn

Garrett said:
Thomas said:
Garrett said:
var imgArray = library.map(filterByName("img"));
var captionArray = library.map(filterByName("caption"));
[...]

Where not supported, Array.prototype.map functionality can be added, as
indicated on MDC page[1].

What a waste. If an Array prototype method should be used here, then
Array.prototype.forEach().

Array.prototype.forEach calls a supplied function on each element in the
Array. It does not create a new Array.

You don't say.
Array.prototype.map creates a new array with the results of calling a
supplied function on each element in the array.

Exactly. If you use Array.prototype.map() you have to iterate *twice* (at
least internally) on the *same* array to get the two resulting arrays.
That's the waste.

var
imgArray = [],
captionArray = [];

library.forEach(function(e, i, a) {
imgArray = e.img;
captionArray = e.caption;
});


PointedEars
 
J

Jorge

  var
    imgArray = [],
    captionArray = [];

  library.forEach(function(e, i, a) {
    imgArray = e.img;
    captionArray = e.caption;
  });


e is undefined...
 
T

Thomas 'PointedEars' Lahn

Jorge said:
Thomas said:
Jorge said:
Thomas 'PointedEars' Lahn wrote:
var
imgArray = [],
captionArray = [];

library.forEach(function(e, i, a) {
imgArray = e.img;
captionArray = e.caption;
});

e is undefined...

Where?


And 'a' is unused...


Yes, that argument does not need to be named here; however, the purpose
here was to show how forEach() could be used -- `a' is a reference to the
array.¹

You have not answered my question, though. I take it then that you found
out you were wrong.


PointedEars
___________
¹
<https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/Array/forEach>
 
J

Jorge

Yes, that argument does not need to be named here; however, the purpose
here was to show how forEach() could be used -- `a' is a reference to the
array.¹

And library is undefined...
You have not answered my question, though.  I take it then that you found
out you were wrong.

Who? Meee?
(It looked to me like ++another of your bugs. :)
 
S

Scott Sauyet

If I find some time tonight or tomorrow, I'll do a few more thorough
benchmarks of multiple versions of the algorithms and see what the
main issues are.

I found a little time to run a number of tests, but I don't have time
now to analyze them. Anyone interested in seeing the raw data from
JSLitmus tests in five browsers running against lists with 10, 100,
1000, and 10000 elements can see my results, and run their own tests
here:

http://scott.sauyet.com/Javascript/Test/LoopTimer/3/

Note that FF seems extremely inconsistent, which makes me worry about
how it's interacting with JSLitmus. The runs shown here seem fairly
representative, though. All the other browsers seem fairly
consistent. The raw data (as a PHP array) is here:

http://scott.sauyet.com/Javascript/Test/LoopTimer/3/results.phps

Cheers,

-- Scott
 
S

Scott Sauyet

And library is undefined...

Oh come on! We've been using similar definitions of library
throughout this thread. You're getting as pedantic as Thomas is,
here.

-- Scott
 
T

Thomas 'PointedEars' Lahn

Scott said:
Oh come on! We've been using similar definitions of library
throughout this thread.
You're getting as pedantic as Thomas is, here.

By contrast, I am being *precise*, stupid.

Then again, imitation is the sincerest form of flattery ;-)


PointedEars
 
J

Jorge

I found a little time to run a number of tests, but I don't have time
now to analyze them.  Anyone interested in seeing the raw data from
JSLitmus tests in five browsers running against lists with 10, 100,
1000, and 10000 elements can see my results, and run their own tests
here:

   http://scott.sauyet.com/Javascript/Test/LoopTimer/3/

Note that FF seems extremely inconsistent, which makes me worry about
how it's interacting with JSLitmus.  The runs shown here seem fairly
representative, though.  All the other browsers seem fairly
consistent.  The raw data (as a PHP array) is here:

   http://scott.sauyet.com/Javascript/Test/LoopTimer/3/results.phps

If your intention is to time with accuracy what comes inside the for
loop, you ought to set library.length to a (much) big(ger) number: you
want the time spent inside the loop to be as close to 100% of the
total time as possible. Iterating a million times over the whole thing
with a badly chosen (small) library.length won't give you any added
accuracy in this regard.

That's why, for example, in the Safari row, you get these completely
different results:

library.length: 10 (items) 10k (items)
pushLookupIncrement: 375,6k 537
pushNewVarIncrement: 622,6k (1,65x) 1.3k (2,42x)

For the faster is the loop is, the bigger the % of error that a small
library.length introduces.

Also, looping through 10000 items, ought to take ~ 1000 times as long
as looping through 10 items, and that's not what your results show:
622,6k !== 1.3k*1000. That's too due to the error I'm talking of: the
10k items result is more accurate and the 10 items figure is off by
100-(622,6/13)= a 52.1% (an error quite big !, the real figure for 10
items was more than 2x that !)

And, as the loop of each tested f() takes a different amount of time
to execute, it's getting a different % of error... (That's the reason
why there's a JSLitmusMultiplier in my (modified) JSLitmus.js)
 
S

Scott Sauyet

If your intention is to time with accuracy what comes inside the for
loop, you ought to set library.length to a (much) big(ger) number: you
want the time spent inside the loop to be as close to 100% of the
total time as possible. Iterating a million times over the whole thing
with a badly chosen (small) library.length won't give you any added
accuracy in this regard.

Well, as I said, I haven't had time to post any analysis. And I still
don't.

But that's not what I'm trying to compare. The raw numbers aren't
comparable across the rows. That wouldn't make sense; in an ideal
world, they would fall by approximately a factor of ten at each
column. The main thing is to see how the different algorithms perform
at various array lengths in the different browsers. Here Safari is
quite consistent. At all array lengths, the final two algorithms are
the fastest, followed by the third and fourth, then the fifth and
sixth, with the first and second trailing far behind.

I think there is something to be gleaned from these examples, but it
will take me a little more time to digest it.

-- Scott
 
J

Jorge

But that's not what I'm trying to compare.

Funny, as the loop is what makes them different.
The raw numbers aren't
comparable across the rows. That wouldn't make sense;

I thought the sole purpose of the tests was to compare the results :)
in an ideal
world, they would fall by approximately a factor of ten at each
column.

Only if/when the time spent in the loop is closer to 100% of the total
execution time.
The main thing is to see how the different algorithms perform
at various array lengths in the different browsers.
Here Safari is quite consistent. (...)

Surprise surprise, increase a little bit library.length to e.g. just
2e4 items and see what happens then.
 
T

Thomas 'PointedEars' Lahn

Scott said:
| 2. overly concerned with minute details or formalisms, esp. in
teaching

- http://dictionary.reference.com/browse/pedantic

Or another way of putting it, being overly precise.

And I do not think I have been *overly* precise. I just would not accept my
words being twisted by wannabes. If you think that to be pedantic, so be
it.
If it's an insult, it's a much more mild one than "stupid". :)

Fair enough :) It is too often *used as* an insult, so I guess I have grown
a bit allergic to it. Sorry.


PointedEars
 
S

Scott Sauyet

And I do not think I have been *overly* precise. I just would not accept my
words being twisted by wannabes. If you think that to be pedantic, so be
it.

Almost always when I think you're being pedantic, I do also think
you're right. I don't think you're being pedantic when you object to
someone twisting your own words. What I find overly precise is when
you correct something that people widely recognize as accurate
*enough*, like when (perhaps from earlier in this thread) you talked
about how it's ES engines not browsers at issue. Sure it's right.
But most knowledgeable people recognize that is true and still prefer
the common usage.
Fair enough :) It is too often *used as* an insult, so I guess I have grown
a bit allergic to it. Sorry.

I do mean it in a slightly insulting way. I really think the dialog
here doesn't merit that sort of correction unless it touches on the
current discussion. And my skin is plenty thick enough to handle
being called stupid. You clearly have plenty of value to offer in the
discussions here; I like it when you focus on those rather than picky
corrections.

Cheers,

-- Scott
 
T

Thomas 'PointedEars' Lahn

Scott said:
[...] What I find overly precise is when you correct something that
people widely recognize as accurate *enough*, like when (perhaps from
earlier in this thread) you talked about how it's ES engines not
browsers at issue. Sure it's right. But most knowledgeable people
recognize that is true and still prefer the common usage.

I do hope you are mistaken here. Or, IOW: I cannot accept people as
knowledgable who say so, because it is obviously false. You should
better double-check your assumptions.


PointedEars
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,082
Messages
2,570,589
Members
47,212
Latest member
JaydenBail

Latest Threads

Top