First off, I really like the design of your demo site, although it is
light on documentation and I'm not sure I grasp the entire purpose.
I think the problem is somewhere in the .filter statements. jQuery
seems to be searching farther than the parent 'clicked' node...when I
added several siblings/children my events were bound to the wrong
input elements, and I put in a px value in one form and the em would
show up somewhere different entirely. Perhaps too many .end()? I can
say for sure that adding a unique ID wherever possible will always
make DOM searching faster. Or, since you also have only one or two
spans/divs of each class, and you already know where they are, it will
be faster to give jQuery the direct path (filter has more overhead
than other methods, it has its own certain uses). Here are a few
options:
$("span .nodeName") //find all .nodeName in span
$("span > .nodeName") //find all .nodeName that are direct children
of span
$
("span").find(".nodeName").doSomething().end().find(".nodePxs").doSomethingElse();
//find all .nodeName in span, doSomething to .nodeName, then
find all .nodePxs of span, doSomethingElse to .nodePxs
Check out this great tutorial to see the many ways to get very
specific with selectors:
http://docs.jquery.com/Tutorials:How_to_Get_Anything_You_Want
You can also Google for "DOM selector speed tests", to get an idea of
what's fastest.
Also, I don't recommend splitting your .'s... jQuery code is more
often written like so:
$(obj).fn({
//function code here
}).fn2(options).fn3();
Not splitting your ) and . makes JSLint happy as well. The first
thing I did was run the code through JSLint and it won't process it
even with "Tolerate sloppy line breaking" enabled. Also, wrapping
your plugin in a closure will protect the $'s from namespace
collision. Search for the many posts on this subject which explain
that concept better than I can.
Hope this helps!
Charles
doublerebel.com
On Sep 7, 3:11 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> Hi guys,
>
> I've been developing small tool for em values (CSS) for quite time. To
> cut unnecessary descriptions, go check it out onhttp://riddle.pl/emcalc/
>
> Now, the problem lays in performance. Try adding 10 nodes, one under
> another and notice that 8th, 9th, 10th (and further) addition works
> terribly slow. I can nearly stall my whole Firefox by adding 15 nodes.
>
> This problem came up after I had rewritten this tool to jQuery
> -http://riddle.pl/emcalc/old/- as you can see problem doesn't exist in
> older version.
>
> I tried profiling but the results Firebug gives me are really odd.
> JS file is here:http://riddle.pl/emcalc/emcalc.js
>
> There are two functions which are responsible for adding node. First
> is event handling (addNode) for buttons, second is DOM creation
> (createNode). I even rewrote createNode to use innerHTML, but the
> result is the same.
>
> I'd really like to ask you guys to take a closer look and tell me what
> am I doing wrong. It's clear to me that after some point jQuery starts
> to iterate on ancestor nodes and it takes centuries.
>
> Thanks in advance.
