Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #20129 > unrolled thread

'pushing' vs direct array assignment ?

Back to article view | Back to comp.lang.javascript

Contents

  'pushing' vs direct array assignment ? "Mel Smith" <med_cutout_syntel@aol.com> - 2013-06-03 13:59 -0600
    Re: 'pushing' vs direct array assignment ? Scott Sauyet <scott.sauyet@gmail.com> - 2013-06-03 13:39 -0700
      Re: 'pushing' vs direct array assignment ? "Mel Smith" <med_cutout_syntel@aol.com> - 2013-06-03 14:46 -0600
      Re: 'pushing' vs direct array assignment ? Stefan Weiss <krewecherl@gmail.com> - 2013-06-04 02:07 +0200
        Re: 'pushing' vs direct array assignment ? "Mel Smith" <med_cutout_syntel@aol.com> - 2013-06-03 18:40 -0600
          Re: 'pushing' vs direct array assignment ? "Mel Smith" <med_cutout_syntel@aol.com> - 2013-06-03 20:38 -0600
          Re: 'pushing' vs direct array assignment ? Martin Leese <please@see.Web.for.e-mail.INVALID> - 2013-06-04 09:11 -0600
            Re: 'pushing' vs direct array assignment ? "Mel Smith" <med_cutout_syntel@aol.com> - 2013-06-04 12:47 -0600
              Re: 'pushing' vs direct array assignment ? Stefan Weiss <krewecherl@gmail.com> - 2013-06-04 22:44 +0200
                Re: 'pushing' vs direct array assignment ? "Mel Smith" <med_cutout_syntel@aol.com> - 2013-06-04 16:02 -0600
              Re: 'pushing' vs direct array assignment ? Martin Leese <please@see.Web.for.e-mail.INVALID> - 2013-06-04 20:24 -0600
                Re: 'pushing' vs direct array assignment ? Gregor Kofler <usenet@gregorkofler.com> - 2013-06-05 14:50 +0200
                  Re: 'pushing' vs direct array assignment ? Martin Leese <please@see.Web.for.e-mail.INVALID> - 2013-06-05 22:38 -0600
                Re: 'pushing' vs direct array assignment ? Tim Slattery <Slattery_T@bls.gov> - 2013-06-05 08:51 -0400
                  OT: Accept-Encoding (was: 'pushing' vs direct array assignment ?) Christoph Becker <cmbecker69@gmx.de> - 2013-06-05 15:23 +0200
    Re: 'pushing' vs direct array assignment ? RobG <rgqld@iinet.net.au> - 2013-06-05 18:12 -0700
      Re: 'pushing' vs direct array assignment ? "Mel Smith" <med_cutout_syntel@aol.com> - 2013-06-06 08:54 -0600

#20129 — 'pushing' vs direct array assignment ?

Hi:

    I build an array in JS that can be from 9 elements thru to nearly 1500 
elements

    I also build a 2-property object to be placed in each of these elements:

    The object to be saved in the array is :

      nuobj = {vrbl1: "vrbl1value", vrbl2: "vrbl2value" }

      // to add this object to this (possibly very big) array should I use 
the 'push' method :
      anames.push(nuobj) ;

      // or should I use direct array assignment
      anames[anames.length] = nuobj ;

    or, is there another preferred way to do this quickly ?

Thank you.

-- 
Mel Smith

[toc] | [next] | [standalone]

#20130

Mel Smith wrote:

>     I build an array in JS that can be from 9 elements thru to nearly 1500
> elements [ ... ]
>
>       // to add this object to this (possibly very big) array should I use
> the 'push' method :
>       anames.push(nuobj) ;
>
>       // or should I use direct array assignment
>       anames[anames.length] = nuobj ;
>
>     or, is there another preferred way to do this quickly ?

One micro-benchmark can be found here:

    <http://jsperf.com/array-index-push/3>

In all the more recent browsers except IE9, `push` is faster.
Unfortunately, in IE8 and IE9, it's quite a bit slower.  And since
that's already the slowest environment, you'll have to make a decision
with that in mind.

But regardless of speed, `push` is certainly cleaner.  And in my mind,
that counts for a fair bit.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#20131

Scott said:

One micro-benchmark can be found here:

    <http://jsperf.com/array-index-push/3>

In all the more recent browsers except IE9, `push` is faster.
Unfortunately, in IE8 and IE9, it's quite a bit slower.  And since
that's already the slowest environment, you'll have to make a decision
with that in mind.

But regardless of speed, `push` is certainly cleaner.  And in my mind,
that counts for a fair bit.


Thanks Scott --- I'll probably revert to .push

-Mel

[toc] | [prev] | [next] | [standalone]

#20134

On 2013-06-03 22:39, Scott Sauyet wrote:
> Mel Smith wrote:
> 
>>     I build an array in JS that can be from 9 elements thru to nearly 1500
>> elements [ ... ]
>>
>>       // to add this object to this (possibly very big) array should I use
>> the 'push' method :
>>       anames.push(nuobj) ;
>>
>>       // or should I use direct array assignment
>>       anames[anames.length] = nuobj ;
>>
>>     or, is there another preferred way to do this quickly ?

The first question I would ask is: are you going to populate your array
once or many times? If it's only once, then just forget about
optimization, it will run too fast to notice with either method.

That was the pragmatic answer ... and now for the fun part :)

> One micro-benchmark can be found here:
> 
>     <http://jsperf.com/array-index-push/3>
> 
> In all the more recent browsers except IE9, `push` is faster.
> Unfortunately, in IE8 and IE9, it's quite a bit slower.  And since
> that's already the slowest environment, you'll have to make a decision
> with that in mind.

That's unexpected. Looking more closely at your test case, there is one
optimization that has a very measurable impact here, at least in Chrome:

For the index insertion test, instead of

   var a = [];           // and append 1000 elements

initialize the array to the proper size first:

   var a = Array(1000);  // and set 1000 elements

Obviously, that doesn't work for the two other tests, but there's a
definite improvement in Chrome for "index insertion":

With a = []:

   UA          | ops/sec
  -------------+------------------------------
   Chrome[1]   |  57,773  for index insertion
   Firefox[2]  |  63,650  for index insertion

With a = Array(1000):

   UA          | ops/sec
  -------------+------------------------------
   Chrome[1]   | 230,493  for index insertion
   Firefox[2]  |  65,300  for index insertion


No significant change in FF.
In Chromium, with the Array() optimization, the index insertion test is
roughly 50% faster than push(); and ~4x faster than with 'a = []';
I'm almost out of RAM, so I can't start a VM and test other browsers.
Stupid old laptops and their 4GB limit...

[1] Chromium 25.0.1364.160
[2] Firefox 21
both running on Ubuntu 12.4 64bit


> But regardless of speed, `push` is certainly cleaner.  And in my mind,
> that counts for a fair bit.

I agree.
Premature micro-optimization is a waste of time (but oh so much fun).

Things were different 6-7 years ago. I remember making exactly this
optimization and getting a very noticable reduction in UI lag. But that
was for an HTML/JS spreadsheet app, so we had a _lot_ of array copy
operations.


- stefan

[toc] | [prev] | [next] | [standalone]

#20136

Stefan said:

> The first question I would ask is: are you going to populate your array
> once or many times? If it's only once, then just forget about
> optimization, it will run too fast to notice with either method.

    Once or twice for the 'big' page --- which I've now shrunk down to 
234K -- and with gzip its now dow to ~~ 57K

>
> That was the pragmatic answer ... and now for the fun part :)
>
>> One micro-benchmark can be found here:
>>
>>     <http://jsperf.com/array-index-push/3>
>>
>> In all the more recent browsers except IE9, `push` is faster.
>> Unfortunately, in IE8 and IE9, it's quite a bit slower.  And since
>> that's already the slowest environment, you'll have to make a decision
>> with that in mind.
>
> That's unexpected. Looking more closely at your test case, there is one
> optimization that has a very measurable impact here, at least in Chrome:
>
> For the index insertion test, instead of
>
>   var a = [];           // and append 1000 elements
>
> initialize the array to the proper size first:
>
>   var a = Array(1000);  // and set 1000 elements
>
> Obviously, that doesn't work for the two other tests, but there's a
> definite improvement in Chrome for "index insertion":
>
> With a = []:
>
>   UA          | ops/sec
>  -------------+------------------------------
>   Chrome[1]   |  57,773  for index insertion
>   Firefox[2]  |  63,650  for index insertion
>
> With a = Array(1000):
>
>   UA          | ops/sec
>  -------------+------------------------------
>   Chrome[1]   | 230,493  for index insertion
>   Firefox[2]  |  65,300  for index insertion
>
>
> No significant change in FF.
> In Chromium, with the Array() optimization, the index insertion test is
> roughly 50% faster than push(); and ~4x faster than with 'a = []';
> I'm almost out of RAM, so I can't start a VM and test other browsers.
> Stupid old laptops and their 4GB limit...
>
> [1] Chromium 25.0.1364.160
> [2] Firefox 21
> both running on Ubuntu 12.4 64bit
>
>
>> But regardless of speed, `push` is certainly cleaner.  And in my mind,
>> that counts for a fair bit.
>
> I agree.
> Premature micro-optimization is a waste of time (but oh so much fun).
>
> Things were different 6-7 years ago. I remember making exactly this
> optimization and getting a very noticable reduction in UI lag. But that
> was for an HTML/JS spreadsheet app, so we had a _lot_ of array copy
> operations.

Hi Stefan:

    I'll see if I have the length of the array available when I start my 
'pushing' or 'insertion' or whatever -- my largest array is approx 1434 
elements, each containing a property with 2 properties.

Thank you for the additional ideas !

-Mel

[toc] | [prev] | [next] | [standalone]

#20138

I said:

">    I'll see if I have the length of the array available when I start my
> 'pushing' or 'insertion' or whatever -- my largest array is approx 1434 
> elements, each containing a property with 2 properties.


Typo:

    I actually have to build *two* arrays each having a maximum sixe of 
approx 1434 elements. Each of the array elements has an object with two 
properties.

    Instead of building the arrays during the 'onload' stage, I move the 
array builder to an 'onclick' function.


-Mel

[toc] | [prev] | [next] | [standalone]

#20141

Mel Smith wrote:
> Stefan said:
> 
>> The first question I would ask is: are you going to populate your array
>> once or many times? If it's only once, then just forget about
>> optimization, it will run too fast to notice with either method.
> 
>     Once or twice for the 'big' page --- which I've now shrunk down to 
> 234K -- and with gzip its now dow to ~~ 57K

I am missing someting, here.  How do you
zip JavaScript code and still get it to run
in the browser?

-- 
Regards,
Martin Leese
E-mail: please@see.Web.for.e-mail.INVALID
Web: http://members.tripod.com/martin_leese/

[toc] | [prev] | [next] | [standalone]

#20143

Martin said:
>
>>     Once or twice for the 'big' page --- which I've now shrunk down to 
>> 234K -- and with gzip its now dow to ~~ 57K
>
> I am missing someting, here.  How do you
> zip JavaScript code and still get it to run
> in the browser?

Hi Martin:

    In your Apache Server configuration file (httpd.conf), ensure the 
following are set:

    LoadModule deflate_module modules/mod_deflate.so

    then in your specific virtual host ensure the following are added:

       AddOutputFilterByType DEFLATE text/html text/plain text/xml
       AddOutputFilterByType DEFLATE text/css text/javascript
       AddOutputFilterByType DEFLATE application/x-javascript


-Mel

[toc] | [prev] | [next] | [standalone]

#20145

On 2013-06-04 20:47, Mel Smith wrote:
> Martin said:
>> I am missing someting, here.  How do you
>> zip JavaScript code and still get it to run
>> in the browser?
> 
> Hi Martin:
> 
>     In your Apache Server configuration file (httpd.conf), ensure the 
> following are set:
[...]

Something I've never understood about mod_deflate: why is there no way
to cache deflated static files? If you have a large script that you want
mod_deflate to compress before sending, it will do so for every single
fresh request. Granted, gzipping a script file is not likely to make a
major impact on a server, but it's still a waste of resources.

Other HTTP servers do have a cache like that (for example, mod_compress
in Lighttpd).

It's not a deal breaker; I still use mod_deflate. I just dislike the
needless waste of cycles when it would be so simple to add a cache
(memory or disk based).

- stefan

[toc] | [prev] | [next] | [standalone]

#20146

Stefan said:

\> Something I've never understood about mod_deflate: why is there no way
> to cache deflated static files? If you have a large script that you want
> mod_deflate to compress before sending, it will do so for every single
> fresh request. Granted, gzipping a script file is not likely to make a
> major impact on a server, but it's still a waste of resources.
>
> Other HTTP servers do have a cache like that (for example, mod_compress
> in Lighttpd).
>
> It's not a deal breaker; I still use mod_deflate. I just dislike the
> needless waste of cycles when it would be so simple to add a cache
> (memory or disk based).


Hi Stefan:

    Because I have approx 67 different 'Big' files available to send out to 
clients, and they are based on data that is usually not changing 'much' over 
the course of a year, I have decided to save a copy of the pre-built  big 
files *when* they are first requested.

    Then, the next time I have a request for one of the 67 (or so) big 
files, I've already got it built, and I simply read it in and then pass it 
to Apache for transmission to the client.

    Also, if I have occasion over the course of the year to update the 'big' 
file, then I manually delete the saved file, and my cgi app notices the 
missing file, rebuilds a new one, saves it, then sends the newly updated 
file to the client.

    I save about 1/4 of a second doing this :)))

-Mel

[toc] | [prev] | [next] | [standalone]

#20153

Mel Smith wrote:

> Martin said:
>> I am missing someting, here.  How do you
>> zip JavaScript code and still get it to run
>> in the browser?
> 
> Hi Martin:
> 
>     In your Apache Server configuration file (httpd.conf), ensure the 
> following are set:
> 
>     LoadModule deflate_module modules/mod_deflate.so
> 
>     then in your specific virtual host ensure the following are added:
> 
>        AddOutputFilterByType DEFLATE text/html text/plain text/xml
>        AddOutputFilterByType DEFLATE text/css text/javascript
>        AddOutputFilterByType DEFLATE application/x-javascript

Thank you, but I don't have control of
people's browsers.

-- 
Regards,
Martin Leese
E-mail: please@see.Web.for.e-mail.INVALID
Web: http://members.tripod.com/martin_leese/

[toc] | [prev] | [next] | [standalone]

#20156

Am 05.06.2013 04:24, Martin Leese meinte:
> Mel Smith wrote:
>
>> Martin said:
>>> I am missing someting, here.  How do you
>>> zip JavaScript code and still get it to run
>>> in the browser?
>>
>> Hi Martin:
>>
>>     In your Apache Server configuration file (httpd.conf), ensure the
>> following are set:
>>
>>     LoadModule deflate_module modules/mod_deflate.so
>>
>>     then in your specific virtual host ensure the following are added:
>>
>>        AddOutputFilterByType DEFLATE text/html text/plain text/xml
>>        AddOutputFilterByType DEFLATE text/css text/javascript
>>        AddOutputFilterByType DEFLATE application/x-javascript
>
> Thank you, but I don't have control of
> people's browsers.

Above configuration settings apply to the server. No need to know or 
control other people's browser.

Gregor

[toc] | [prev] | [next] | [standalone]

#20162

Gregor Kofler wrote:
> Am 05.06.2013 04:24, Martin Leese meinte:
>> Mel Smith wrote:
>>
>>> Martin said:
>>>> I am missing someting, here.  How do you
>>>> zip JavaScript code and still get it to run
>>>> in the browser?
>>>
>>> Hi Martin:
>>>
>>>     In your Apache Server configuration file (httpd.conf), ensure the
>>> following are set:
>>>
>>>     LoadModule deflate_module modules/mod_deflate.so
>>>
>>>     then in your specific virtual host ensure the following are added:
>>>
>>>        AddOutputFilterByType DEFLATE text/html text/plain text/xml
>>>        AddOutputFilterByType DEFLATE text/css text/javascript
>>>        AddOutputFilterByType DEFLATE application/x-javascript
>>
>> Thank you, but I don't have control of
>> people's browsers.
> 
> Above configuration settings apply to the server. No need to know or 
> control other people's browser.

Thank you for the clarification.
Unfortunately I use a free Web hosting
company (Tripod.com), so do not have control
of the server either.

I had hoped that the latest browsers would
download and unzip zipped JavaScript code
out of the box.  I guess not.

-- 
Regards,
Martin Leese
E-mail: please@see.Web.for.e-mail.INVALID
Web: http://members.tripod.com/martin_leese/

[toc] | [prev] | [next] | [standalone]

#20157

Martin Leese <please@see.Web.for.e-mail.INVALID> wrote:

>Mel Smith wrote:
>
>> Martin said:
>>> I am missing someting, here.  How do you
>>> zip JavaScript code and still get it to run
>>> in the browser?
>> 
>> Hi Martin:
>> 
>>     In your Apache Server configuration file (httpd.conf), ensure the 
>> following are set:
>> 
>>     LoadModule deflate_module modules/mod_deflate.so
>> 
>>     then in your specific virtual host ensure the following are added:
>> 
>>        AddOutputFilterByType DEFLATE text/html text/plain text/xml
>>        AddOutputFilterByType DEFLATE text/css text/javascript
>>        AddOutputFilterByType DEFLATE application/x-javascript
>
>Thank you, but I don't have control of
>people's browsers.

Those are server commands, telling the server to compress those files
before shipping them. But is it true that all browsers know what to do
when they receive such a file?

-- 
Tim Slattery
Slattery_T@bls.gov

[toc] | [prev] | [next] | [standalone]

#20158 — OT: Accept-Encoding (was: 'pushing' vs direct array assignment ?)

Tim Slattery wrote:
> Martin Leese <please@see.Web.for.e-mail.INVALID> wrote:
> 
>> Mel Smith wrote:
>>
>>> Martin said:
>>>> I am missing someting, here.  How do you
>>>> zip JavaScript code and still get it to run
>>>> in the browser?
>>>
>>> Hi Martin:
>>>
>>>     In your Apache Server configuration file (httpd.conf), ensure the 
>>> following are set:
>>>
>>>     LoadModule deflate_module modules/mod_deflate.so
>>>
>>>     then in your specific virtual host ensure the following are added:
>>>
>>>        AddOutputFilterByType DEFLATE text/html text/plain text/xml
>>>        AddOutputFilterByType DEFLATE text/css text/javascript
>>>        AddOutputFilterByType DEFLATE application/x-javascript
>>
>> Thank you, but I don't have control of
>> people's browsers.
> 
> Those are server commands, telling the server to compress those files
> before shipping them. But is it true that all browsers know what to do
> when they receive such a file?

A client may send an Accept-Encoding header[1] to tell the server about
the encodings he is able to handle.  The server should not send any
response that is not acceptable according to this request header.

[1] <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.3>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#20161

On Tuesday, June 4, 2013 5:59:44 AM UTC+10, Mel Smith wrote:
[...]
>     or, is there another preferred way to do this quickly ?

In order to determine a preference for one method or another, it is important to establish the criteria for evaluation. Some that might apply (in approximate order of importance) are:

1. Unintended side effects: iterating over an array by index may create undefined properties, but if you are creating a contiguous list from zero then it doesn't matter.

2. Support in likely host environments: very old browsers don't support Array.prototype.push, so if you need to support those it's better to use direct assignment (or add a push method if feature detection shows it's missing, which may be another question). If you use direct assignment, you never need to worry. But there must be very few browsers on the web that don't have push.

3. Performance: as has been noted, this goes both ways. For 1,500 items, I suspect it won't make much difference on a modern computer, but might be significant in the types of environments where support for push is more likely to be lacking.

4. Maintainability (code clarity): I don't think there are any issues here with one approach or the other.

5. Number of characters to type: direct assignment saves 3 characters, not worth dying in a ditch over (IMHO of course).

So on balance, for code expected to be widely used on the web, I'd go with direct assignment, but be happy with push if it was used.

Applying the above analysis to your context might give a different result.

> or, is there another preferred way to do this quickly ? 

Depending on your target environment, JavaScript™ 1.7 (released in October 2006 with Firefox 2) introduced iterators and generators[1]. But that approach doesn't get a very high score for the support criterion if you need to work with environments other than those compliant with JavaScript™ 1.7.

1. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Iterators_and_Generators

-- 
Rob

[toc] | [prev] | [next] | [standalone]

#20168

Rob said:

In order to determine a preference for one method or another, it is 
important to establish the criteria for evaluation. Some that might apply 
(in approximate order of importance) are:

1. Unintended side effects: iterating over an array by index may create 
undefined properties, but if you are creating a contiguous list from zero 
then it doesn't matter.

2. Support in likely host environments: very old browsers don't support 
Array.prototype.push, so if you need to support those it's better to use 
direct assignment (or add a push method if feature detection shows it's 
missing, which may be another question). If you use direct assignment, you 
never need to worry. But there must be very few browsers on the web that 
don't have push.

3. Performance: as has been noted, this goes both ways. For 1,500 items, I 
suspect it won't make much difference on a modern computer, but might be 
significant in the types of environments where support for push is more 
likely to be lacking.

4. Maintainability (code clarity): I don't think there are any issues here 
with one approach or the other.

5. Number of characters to type: direct assignment saves 3 characters, not 
worth dying in a ditch over (IMHO of course).

So on balance, for code expected to be widely used on the web, I'd go with 
direct assignment, but be happy with push if it was used.

Applying the above analysis to your context might give a different result.

> or, is there another preferred way to do this quickly ?

Depending on your target environment, JavaScript™ 1.7 (released in October 
2006 with Firefox 2) introduced iterators and generators[1]. But that 
approach doesn't get a very high score for the support criterion if you need 
to work with environments other than those compliant with JavaScript™ 1.7.

1. 
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Iterators_and_Generators


Hi Rob:

    The above gives me much more to 'chew on' and puzzle over.  Also, the 
link above on 'Iterators ...' will provide substance for this evening's 
reading  -- The .next() function is completely new to me.

Thank you.

-Mel 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web