And a quick reply to myself.
It's also quicker (though we are talking like 1 ms quicker), to
refactor the code to never create the $j(<li>) at all, and instead to
directly inject the HTML into the page, and then manipulate after the
fact, instead of before hand.
Eli -- Still curious to know why the original is so slow, as well as
why this case exists.
On Nov 13, 11:44 am, Eli <[EMAIL PROTECTED]> wrote:
> So, I had some code that was performing very badly. Specifically
> tracked it down to the following:
>
> var li = $j('\
> <li>\
> <input type="checkbox" checked="checked" id="ecb-' + shortKey
> + '" />\
> <label for="ecb-' + shortKey + '">\
> <span class="left">' + optionKey + '</span>\
> <span class="right" id="epr-' + shortKey + '"></span>\
> </label>\
> </li>\
> ');
>
> I was doing that, in order to create a new LI element with the
> appropriate 'stuff' filled in. That I then did some other
> manipulations to, and returned from a function, for another part of
> the code to figure out where exactly to 'insert' it into the document.
>
> I discovered through Firebug, that this was taking over 500ms to
> execute!!
>
> I changed it to the following code, and it now takes 13ms to execute
> instead:
> var li = $j('<li/>');
> li.html('\
> <input type="checkbox" checked="checked" id="ecb-' + shortKey
> + '" />\
> <label for="ecb-' + shortKey + '">\
> <span class="left">' + optionKey + '</span>\
> <span class="right" id="epr-' + shortKey + '"></span>\
> </label>\
> ');
>
> Much better.
>
> But the question is, WHY does the one-line form of this make a
> difference? In fact, according to the documentation, this is exactly
> what the actual jQuery code itself is supposed to be doing in the
> first case:
>
> "Internally, an element is created and its innerHTML property set to
> the given markup. It is therefore both quite flexible and limited."
>
> But, obviously, something isn't working 'quite right'.
>
> Thoughts?
> Eli
