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

Groups > comp.lang.javascript > #18011

Re: Two versions of code - advantages and differences

Show all headers | View raw

W dniu 2013-01-07 02:35, Stefan Weiss pisze:
> On 2013-01-06 22:30, Cezary Tomczyk wrote:
>> I've just wrote something like this:
>>
>> var main = {
>>       [...]
>>
>>       apply : (function(){
>>           var tempImg = document.createElement('img'),
>>               t, img;
>>           tempImg.width = '10';
>>           tempImg.height = '10';
>>
>>           return function(o){
>>               img = tempImg.cloneNode(false);
>>               img.alt = o.alt;
>>               img.src = o.src;
>>               t = document.createElement('span');
>>               t.appendChild(document.createTextNode('\u00a0'));
>>               t.appendChild(img);
>>               t.appendChild(document.createTextNode('\u00a0'));
>>               window.setTimeout(function(){ examplefn(t); }, 100);
>>           };
>>       }
>
>         )(),

Ah, yes. A typo. My mistake.

>>
>>       [...]
>> };
>>
>> As I understand (correct me if I am wrong) this is inefficient because:
>>
>> * closure need extra memory and will be always in memory because
>> returned function refers to variables that are outside of returned function.
>
> In your example, the returned function closes over tempImg. If this
> element is actually needed, you will have to store it _somewhere_. It
> won't take up more memory just because it's in a closure. If it's not
> needed, and you're concerned about memory usage, then don't create it.

I create it because I discovered that cloning node with already defined 
properties is faster than creating node with new properties.

> Keeping a value around in a closure when it's not strictly needed can be
> convenient (from a programmer's perspective), and it can speed up
> execution later on, at the cost of some memory. You could look at it as
> an optimization measure that favors speed over memory usage.

I know that this can depend on situation, eg. more complex things and 
results can be cached. After some discussion here I know that I would 
write it now in a much simpler way. No extra closure here is needed.

> In another message, you asked about the performance penalty of closures
> compared to non-closure* functions. I was about to reply that the
> difference is insignificant, but thought I'd better provide a benchmark
> for support. That's when I ran into my little benchmark problem with
> Chrome, and I forgot to reply :-/  Anyway, having a closure does not by
> itself cause a noticable difference in performance. You'd need millions
> of calls to see any difference at all, and then the result is mixed. In
> some cases/implementations, the closure variant was actually executed
> faster than the function+variable variant. You'll have to take my word
> for that or test it yourself, because I'm done with benchmarks for today :)

Yes, I saw your post and even I did some tests. The results are 
surprised for me. Google Chrome and Safari was incredibly fast, while 
Firefox and Opera was very slow.

> (* technically, every function call creates a closure, but that
> definition of a closure is so broad that it becomes almost useless)

Actually, yes.

>> * "apply" is parsed immediately which is not needed always
>
> Nitpick: the whole script is parsed before anything can be executed. You
> probably meant to say that the anonymous function is executed
> immediately, and a tempImg element is created even though it may not be
> needed.

Indeed. Execution and parsing is not the same thing.

> Creating a handful of elements when a script is loaded won't make much
> of a difference. If you still want to reduce the overhead, you could
> initialize such elements lazily (ie, only when they are needed):
>
>     apply: (function () {
>
>         var tempImg;
>
>         function prepareImg() {
>             if (!tempImg) {
>                 tempImg = document.createElement("img");
>                 tempImg.width = 10;
>                 tempImg.height = 10;
>             }
>         }
>
>         return function (o) {
>             prepareImg();    // (or inlined)
>             ...
>         };
>
>     })(),
>
> To be honest, I don't see the need for a tempImg (or a closure) at all
> in this method. The element just gets cloned every time apply() is
> called. Why not simply create the actual image element when you need it?

As I mentioned above: cloneNode working faster than creating new node 
and add new properties. Well, on the other hand this could be called as 
a "premature optimization" ;-)

I think that after some discussion in this topic I would rather rewrite 
my code and use much more simpler version. No closure needed.

>> Anything else inefficient or wrong?
>
> Nothing wrong, just more from the nitpick department:
>
> I would avoid the name "apply" for a method. It's not wrong, but it can
> lead to confusion for others who read your code.

That was only an example, but I know that developer should / must avoid 
using reserved words or words that can confuse others.

> The 't' and 'img' variables should be declared where they are used, not
> in the surrounding function.

Ok, because every function is a closure then 't', 'img' are really 
outside of returned function. So, they should be defined inside returned 
function.

> \u00a0: ten years ago, a typical HTML document was littered with
> non-breaking spaces, but they are rarely needed today (except when you
> actually need a non-breaking space between words). Manually creating DOM
> text nodes for them is a waste. Use CSS to create fillers and margins
> instead.

Nice idea, but for some reason I can not see non-breaking-space (and any 
other content) before and after img. Tested on Firefox 17.0.1 and IE 9 
(Windows 7, 64 bit). See:

http://jsfiddle.net/w7BAu/

> tempImg.width = '10';  - should be an number, not a string.

Ok

> HTH,

Yes, it helps. Thanks.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Two versions of code - advantages and differences Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-01-03 22:58 +0100
  Re: Two versions of code - advantages and differences Stefan Weiss <krewecherl@gmail.com> - 2013-01-04 00:41 +0100
    Re: Two versions of code - advantages and differences Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-01-04 09:15 +0100
      Re: Two versions of code - advantages and differences Gregor Kofler <usenet@gregorkofler.com> - 2013-01-04 11:26 +0100
        Re: Two versions of code - advantages and differences Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-01-04 14:29 +0100
          Re: Two versions of code - advantages and differences Gregor Kofler <usenet@gregorkofler.com> - 2013-01-04 14:56 +0100
            Re: Two versions of code - advantages and differences Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-01-04 16:52 +0100
    Re: Two versions of code - advantages and differences Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-01-04 09:19 +0100
  Re: Two versions of code - advantages and differences Gregor Kofler <usenet@gregorkofler.com> - 2013-01-04 11:25 +0100
  Re: Two versions of code - advantages and differences Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-01-04 15:31 +0100
    Re: Two versions of code - advantages and differences David Mark <dmark.cinsoft@gmail.com> - 2013-01-05 08:37 -0800
      Re: Two versions of code - advantages and differences Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-01-05 18:14 +0100
        Re: Two versions of code - advantages and differences David Mark <dmark.cinsoft@gmail.com> - 2013-01-05 10:51 -0800
          Re: Two versions of code - advantages and differences Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-01-05 20:46 +0100
            Re: Two versions of code - advantages and differences David Mark <dmark.cinsoft@gmail.com> - 2013-01-05 17:12 -0800
              Re: Two versions of code - advantages and differences David Mark <dmark.cinsoft@gmail.com> - 2013-01-06 17:43 -0800
              Re: Two versions of code - advantages and differences Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-01-07 03:58 +0100
                Re: Two versions of code - advantages and differences David Mark <dmark.cinsoft@gmail.com> - 2013-01-06 19:23 -0800
                Re: Two versions of code - advantages and differences Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-01-07 05:19 +0100
    Re: Two versions of code - advantages and differences Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-01-06 22:30 +0100
      Re: Two versions of code - advantages and differences Stefan Weiss <krewecherl@gmail.com> - 2013-01-07 02:35 +0100
        Re: Two versions of code - advantages and differences Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-01-07 22:45 +0100
      Re: Two versions of code - advantages and differences Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-01-07 04:36 +0100
        Re: Two versions of code - advantages and differences Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-01-07 23:06 +0100
          Re: Two versions of code - advantages and differences Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-01-08 12:35 +0100
            Re: Two versions of code - advantages and differences Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-01-09 08:34 +0100
  Re: Two versions of code - advantages and differences David Mark <dmark.cinsoft@gmail.com> - 2013-01-05 09:13 -0800
    Re: Two versions of code - advantages and differences Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-01-06 11:09 +0100
      Re: Two versions of code - advantages and differences David Mark <dmark.cinsoft@gmail.com> - 2013-01-06 12:56 -0800
        Re: Two versions of code - advantages and differences Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-01-07 22:53 +0100
  Re: Two versions of code - advantages and differences Luc Yen <luc@goal.tw> - 2013-01-05 12:54 -0800
    Re: Two versions of code - advantages and differences Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-01-06 21:38 +0100

csiph-web