[jQuery] Re: Quite big performance issue
Thanks, I realized what you were going for after studying it, I think you should put that explanation on the website! I understand the troubles of px --> em conversion and also why em's are important, however you have a unique solution to those troubles that wasn't obvious to me. Glad to hear it's getting good use, I'll have to fire it up myself when I do my next page revision. Charles On Sep 8, 11:04 am, "Piotr Petrus" <[EMAIL PROTECTED]> wrote: > Charles, when you make CSS for webpage and you use em values instead > of pixels, it's quite difficult to remember real (pixel) values, > because of em's nature. > > body - you set font-size as 1em and it's 16px > within that body you have div#header and you set font-size to 0.5em > and that's 8px > within #header you have paragraph and you set font-size to 1em, but > it's not 16px. It's 8px. > > That's why I need a tree. This tool is used by many people as I can > tell from incoming links, save count at del.icio.us and many mails. > More importantly - I created it beacuse I was tired of calculating > this stuff by myself and taking notes on paper. ;) You should read > about em values if you don't know why they're important :) > > I guess I'll have to rewrite this tool to plain DOM methods again. Or > at least this frickin' node addition. :) > -- > Piotr Petrushttp://riddle.pl
[jQuery] Re: Quite big performance issue
Charles, when you make CSS for webpage and you use em values instead of pixels, it's quite difficult to remember real (pixel) values, because of em's nature. body - you set font-size as 1em and it's 16px within that body you have div#header and you set font-size to 0.5em and that's 8px within #header you have paragraph and you set font-size to 1em, but it's not 16px. It's 8px. That's why I need a tree. This tool is used by many people as I can tell from incoming links, save count at del.icio.us and many mails. More importantly - I created it beacuse I was tired of calculating this stuff by myself and taking notes on paper. ;) You should read about em values if you don't know why they're important :) I guess I'll have to rewrite this tool to plain DOM methods again. Or at least this frickin' node addition. :) -- Piotr Petrus http://riddle.pl
[jQuery] Re: Quite big performance issue
Thanks Michael, good to know, I guess I should be reading more of
y'all's code. I got into the habit of putting my () on different
lines due to long nested functions.
Piotr:
Is your goal with this to enable users to create their own mock DOM
tree, name each node to match an element in the tree, convert their px
sizes to em, and save the structure for updating later? Which would
be why you want many nodes, to emulate an existing DOM tree
somewhere? So it helps promote accessiblity? Hmm... I'm trying to
solve this 'riddle'.
Charles
On Sep 7, 10:47 pm, "Michael Geary" <[EMAIL PROTECTED]> wrote:
> > > From: polyrhythmic
> > > 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.
> > From: Michael Geary
> > Well... The style that Piotr was using:
>
> >$('#settings')
> > .bind('submit', this.saveSettings)
> > .find('[EMAIL PROTECTED]').bind('keyup', this, function(e) {
> > ...
>
> > happens to be the style that John and I and a number of other
> > jQuery developers and users prefer. I think it is by far the
> > cleanest way to format chained methods.
>
> And just so there's no misunderstanding, if you prefer a different format,
> that's cool. I just wouldn't go changing this if the only
> reason is to placate JSLint. JSLint can be a very useful tool, but it can be
> overly fussy about a few things like this.
>
> -Mike
[jQuery] Re: Quite big performance issue
Hello everyone I'd like to apologize for the way I presented my problem – as Charles wrote, it'd be nicer to see just the node addition. It spawns a lot of communication problems I think, because the keyup events working on whole tree and session handlers are actually fast as hell, and the only thing that is terribly slow is the addition of new nodes (in a exponential way, mind you), as you can probably tell. To prove it, I commented the event handlers with calcFields and so on, leaving only main 3 event for adding nodes and deleting it. It's still the same. I'm quite worried because I tried to optimize css queries and it still fails – adding 10th, 11th, 12th… node is still more and more slower. It's not like I have to wait 1 sec because I do a lot of operation there. It takes 5, 10, 29 and even 70 sec later and I'm afraid to see how bad it can be later. I just don't get it how the change can be exponential because I'm using quite simple code. I'll try stripping down everything except my main problem and show it to you later if the issue is still there. Thanks for your time though, appreciate it. -- Piotr Petrus http://riddle.pl
[jQuery] Re: Quite big performance issue
Hi,
I took a moment to look are your stuff and I am not sure what you are
expecting.
Of course your jQuery version will be slower than your native
version.
I personally think it can reduced tremedously, there is alot of
overhead in there for a rather simply application. I can see
immediately that you have a high overhead keyboard handler in
calcFields(). Now does it mean much? Not sure, how many characters
are the users typing - 1 or 2 digits?
Did you expect it to be any faster or the same? They are not even
doing the same thing. Your jqQuery is doing alot more functionality.
The your jQuery calcField() keyboard handler is doing:
- a key parser (changeFieldvalue)
- a class added or filter (savedStateHandler)
- propagates thru each child and child-sibling via jQuery searching/
finding.
This is apple and oranges. Obviously it will be slower. Anyway, if
you want to profile it, add the following firebug console commands at
the beginning and end and you will see where all your overhead is add
just with a single keystroke. Add your 10-15 childs and siblings
before you run a single keystoke profile:
calcFields: function(e) {
console.profile();
.
console.profileEnd();
},
You will be able to see where you can optimize this.
--
HLS
On Sep 7, 11:38 pm, "Piotr Petrus" <[EMAIL PROTECTED]> wrote:
> Hi Charles,
>
> Thanks for taking your time to investigate my issue
>
> However, the site you see is not a demo, it's "fully" functional
> calculator for css dimensions. :) When you start typing, you fire
> different events, and - yes - they affect whole tree & that's
> intentional.
>
> But the thing that only bugs me is adding new nodes. I'll try
> optimizing filters more aggresively, but unfortunately I did similar
> thing before and it didn't make a difference.
>
> About other things that you've said: I don't get the JSLint comment;
> and my code don't need to be wrapped in closure because it's not a
> plugin and it won't be used anywhere else. :)
>
> --
> Piotr Petrushttp://riddle.pl
[jQuery] Re: Quite big performance issue
> > From: polyrhythmic
> > 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.
> From: Michael Geary
> Well... The style that Piotr was using:
>
>$('#settings')
> .bind('submit', this.saveSettings)
> .find('[EMAIL PROTECTED]').bind('keyup', this, function(e) {
> ...
>
> happens to be the style that John and I and a number of other
> jQuery developers and users prefer. I think it is by far the
> cleanest way to format chained methods.
And just so there's no misunderstanding, if you prefer a different format,
that's cool. I just wouldn't go changing this if the only
reason is to placate JSLint. JSLint can be a very useful tool, but it can be
overly fussy about a few things like this.
-Mike
[jQuery] Re: Quite big performance issue
> From: polyrhythmic
> 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.
Well... The style that Piotr was using:
$('#settings')
.bind('submit', this.saveSettings)
.find('[EMAIL PROTECTED]').bind('keyup', this, function(e) {
...
happens to be the style that John and I and a number of other jQuery developers
and users prefer. I think it is by far the cleanest
way to format chained methods.
If JSLint doesn't like it, then as I see it that's JSLint's problem. :-)
Fortunately, "Tolerate sloppy line breaking" turns off
those particular warnings, and most of the rest of JSLint's warnings on the .js
file (http://riddle.pl/emcalc/emcalc.js) look like
they are worth fixing.
-Mike
[jQuery] Re: Quite big performance issue
You're welcome Piotr,
By demo I mean demonstration. Since you're showing the world what to
do with your code/program, the demonstration could use more
explanation as well. If I understood better what you're trying to
accomplish, I could be more helpful. Here's what I see are the main
areas to improve:
1. Don't use .filter(). I looked at the jQuery source, and .filter()
invokes many RegExs, which is definitely slowing the code down. Also,
you could target your DOM elements more specifically, as in my earlier
examples.
2. Run your code through JSLint by the talented Douglas Crockford:
http://www.jslint.com
There are serious line-break issues in your code, which JSLint will
point out, and it prevents me from analyzing your code for other
mistyped characters.
Also, check out http://docs.jquery.com/Events . Binding click,
keypress, and other events is built-in to the jQuery code, so instead
of:
$(element).bind("click", this, fn(e));
Just write:
$(element).click( fn(e) );
Sorry about the plugin/closure thing, I misunderstood what you're
trying to do. I'm curious to see where you go from here,
Charles
On Sep 7, 8:38 pm, "Piotr Petrus" <[EMAIL PROTECTED]> wrote:
> Hi Charles,
>
> Thanks for taking your time to investigate my issue
>
> However, the site you see is not a demo, it's "fully" functional
> calculator for css dimensions. :) When you start typing, you fire
> different events, and - yes - they affect whole tree & that's
> intentional.
>
> But the thing that only bugs me is adding new nodes. I'll try
> optimizing filters more aggresively, but unfortunately I did similar
> thing before and it didn't make a difference.
>
> About other things that you've said: I don't get the JSLint comment;
> and my code don't need to be wrapped in closure because it's not a
> plugin and it won't be used anywhere else. :)
>
> --
> Piotr Petrushttp://riddle.pl
[jQuery] Re: Quite big performance issue
You're welcome Piotr,
By demo I mean demonstration. Since you're showing the world what to
do with your code/program, the demonstration could use more
explanation as well. If I understood better what you're trying to
accomplish, I could be more helpful. Here's what I see are the main
areas to improve:
1. Don't use .filter(). I looked at the jQuery source, and .filter()
invokes many RegExs, which is definitely slowing the code down. Also,
you could target your DOM elements more specifically, as in my earlier
examples.
2. Run your code through JSLint by the talented Douglas Crockford:
http://www.jslint.com
There are serious line-break issues in your code, which JSLint will
point out, and it prevents me from analyzing your code for other
mistyped characters.
Also, check out http://docs.jquery.com/Events . Binding click,
keypress, and other events is built-in to the jQuery code, so instead
of:
$(element).bind("click", this, fn(e));
Just write:
$(element).click( fn(e) );
Sorry about the plugin/closure thing, I misunderstood what you're
trying to do. I'm curious to see where you go from here,
Charles
On Sep 7, 8:38 pm, "Piotr Petrus" <[EMAIL PROTECTED]> wrote:
> Hi Charles,
>
> Thanks for taking your time to investigate my issue
>
> However, the site you see is not a demo, it's "fully" functional
> calculator for css dimensions. :) When you start typing, you fire
> different events, and - yes - they affect whole tree & that's
> intentional.
>
> But the thing that only bugs me is adding new nodes. I'll try
> optimizing filters more aggresively, but unfortunately I did similar
> thing before and it didn't make a difference.
>
> About other things that you've said: I don't get the JSLint comment;
> and my code don't need to be wrapped in closure because it's not a
> plugin and it won't be used anywhere else. :)
>
> --
> Piotr Petrushttp://riddle.pl
[jQuery] Re: Quite big performance issue
Hi Charles, Thanks for taking your time to investigate my issue However, the site you see is not a demo, it's "fully" functional calculator for css dimensions. :) When you start typing, you fire different events, and - yes - they affect whole tree & that's intentional. But the thing that only bugs me is adding new nodes. I'll try optimizing filters more aggresively, but unfortunately I did similar thing before and it didn't make a difference. About other things that you've said: I don't get the JSLint comment; and my code don't need to be wrapped in closure because it's not a plugin and it won't be used anywhere else. :) -- Piotr Petrus http://riddle.pl
[jQuery] Re: Quite big performance issue
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.
