Re: [jQuery] Form plugin's serialize(): performance issues
Brian ha scritto: Perhaps there should be a FastSerialize method, that doesn't guarantee semantic order, and uses every shortcut to cut down on dom-walking time? This way, the developer can choose whether to use the faster method, or the slower-but-correctly-ordered method. - Brian Can you explain why processing elements in semantic order is important? Two reasons: $(input | select).eq(0) This should access the first matched element of input or select - when the order isn't important, you'll never know which element will actually be first. It's important that the element is actually the first element in the document. Secondly, when serializing forms, the order of the elements that comes back is frequently important - having a different order can cause problems for certain applications. Thanks for your answers. I agree with Brian about the need of a FastSerialize method. I don't know how many applications can get in troubles receiving forms data in a not semantic order. Maybe it is worth considering to introduce an OrderedSerialize method, using the current ordered but slow implementation, and use a fast but unordered implementation as the default one. Ah, yes, this is an incompatible change for those applications :) For my needs I preferred to use the fast way. Here is the code of the modified serialize I use: http://zone.spip.org/trac/spip-zone/browser/_plugins_/_dev_/-jQuery/form.js Renato ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Form plugin's serialize(): performance issues
I agree with Brian about the need of a FastSerialize method. Renato, I've been benchmarking these serialize methods on a form with one select element that has 2000 options. Using the Firebug timer to capture elapsed time for the serialize call I see negligible difference in your impl and the one I posted on this thread. The current impl in the form plugin is noticeably slower. Here's the results: Current form plugin - average over 10 calls: 850ms For-loop impl - average over 10 calls: 337ms input,textarea,select impl - average over 10 calls: 379ms Granted this is just one benchmark (in FF on windows), but I think the for-loop impl holds up pretty well. Mike Geary, I haven't yet implemented your outline. I like it stylistically, but I not expecting performance improvements. Would you agree or would you expect it to be faster than Renato's impl? Mike ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Form plugin's serialize(): performance issues
Mike, Where are you finding the Firebug timer? I'm not seeing much of a performance boost using the for loop, but without a true timer, it's not a fair test... m. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Alsup Sent: Thursday, September 28, 2006 6:22 AM To: jQuery Discussion. Subject: Re: [jQuery] Form plugin's serialize(): performance issues I agree with Brian about the need of a FastSerialize method. Renato, I've been benchmarking these serialize methods on a form with one select element that has 2000 options. Using the Firebug timer to capture elapsed time for the serialize call I see negligible difference in your impl and the one I posted on this thread. The current impl in the form plugin is noticeably slower. Here's the results: Current form plugin - average over 10 calls: 850ms For-loop impl - average over 10 calls: 337ms input,textarea,select impl - average over 10 calls: 379ms Granted this is just one benchmark (in FF on windows), but I think the for-loop impl holds up pretty well. Mike Geary, I haven't yet implemented your outline. I like it stylistically, but I not expecting performance improvements. Would you agree or would you expect it to be faster than Renato's impl? Mike ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/ ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Form plugin's serialize(): performance issues
Where are you finding the Firebug timer? I'm not seeing much of a
performance boost using the for loop, but without a true timer, it's not
a fair test...
Look at the measurement section here:
http://www.joehewitt.com/software/firebug/docs.php
My test func looks like this:
$(function() {
$(#go).click(function() {
window.console.time(mike);
var x = $('#theform').serialize();
window.console.timeEnd(mike);
alert (x);
return false;
});
});
I'm alerting the response just to make sure each serialize method is
working correctly. I don't know that this is a fair test either,
but it's one data point anyway.
Mike
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Form plugin's serialize(): performance issues
From: Mike Alsup Mike Geary, I haven't yet implemented your outline. I like it stylistically, but I not expecting performance improvements. Would you agree or would you expect it to be faster than Renato's impl? I think it depends on the nature of the form. For a form with a SELECT containing a large number of OPTIONs but not very many other fields, I would expect my approach to be very fast since it doesn't loop through the OPTIONs at all. I don't know how it compares with Renato's version - it may depend on how this jQuery expression is implemented: $( 'input,textarea,select', this ) If that does three separate GetElementsByTagName() calls, it should be very fast - but it would not preserve the source order if that's a concern. If that expression loops through all the child elements, then it would be slower in the many-OPTIONs case. -Mike ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
[jQuery] Form plugin's serialize(): performance issues
I've run into a significant performance issue with the form plugin's
serialize method; not a bug per se, but definitely a show-stopper for
me. The problem is that I have a form with a select element, which has
around 250 options. The serialize method grabs *all* child elements of
the form before operating on any of them, like so:
$('*', this).each( ... );
This is awfully inefficient, especially considering each element type is
handled by name anyway in the following code. Perhaps it would be best
to define the top-level or containing elements first, then grab just
those (i.e., excluding OPTIONs):
var elems = ['INPUT', 'SELECT', 'TEXTAREA', ...]
$(elems.join('|'), this).each( ... );
So instead of looking through each OPTION for a selected property, the
parent SELECT could be checked for its selectedIndex property. Any
thoughts?
m.
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Form plugin's serialize(): performance issues
Mike Alsup schrieb:
Seems to be faster rewriting it with a for loop instead of using each.
Matt, can you confirm?
Mike
Believe it or not, make it a reverse for loop, it is even faster:
for (var k = options.length - 1; k = 0; k--) {
}
Cheers, Klaus
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Form plugin's serialize(): performance issues
Oops, I missed a 'return'. This:
if (el.type == 'image' el.form.clicked_x)
return a.push(
{name: el.name+'_x', value: el.form.clicked_x},
{name: el.name+'_y', value: el.form.clicked_y}
);
Should be:
if (el.type == 'image' el.form.clicked_x) {
a.push(
{name: el.name+'_x', value: el.form.clicked_x},
{name: el.name+'_y', value: el.form.clicked_y}
);
continue;
}
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Form plugin's serialize(): performance issues
Believe it or not, make it a reverse for loop, it is even faster: Except that we want to process them in semantic order! :-) ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Form plugin's serialize(): performance issues
From: Mike Alsup
Seems to be faster rewriting it with a for loop instead of using each.
Matt, can you confirm?
Here's a skeleton of another way to approach the problem. Instead of
enumerating every element inside the form, it looks at each nodeName as it
goes and decides what to do from there.
This code is off the cuff and incomplete! :-)
$.fn.serialize = function() {
var a = [];
var taggers = {
'#COMMENT':ignore, '#TEXT':ignore,
INPUT:add, TEXTAREA:add, SELECT:select
};
this.each( function() {
fields( this );
});
function fields( e ) {
var tag = e.nodeName.toUpperCase();
( taggers[tag] || nest )( e );
}
function nest( e ) {
for( e = e.firstChild; e; e = e.nextSibling ) {
fields( e );
}
}
function ignore( e ) {
}
function select( e ) {
// not sure if you just want selectedIndex or go get the OPTION
a.push({ name:e.name, value:e.selectedIndex });
}
function add( e ) {
// some existing $.fn.serialize code goes here, ending with...
a.push({ name:n, value:e.value });
});
return a;
};
-Mike
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Form plugin's serialize(): performance issues
John,
If you say jQuery doesn't support the OR selector '|', then I'm
confused. I have a form with one SELECT element and several INPUTs.
Check out the following results from Firebug:
$('INPUT', $('#myform')).length
6
$('INPUT|SELECT', $('#myform')).length
7
That's what I expected as a result.. can you explain?
m.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of John Resig
Sent: Wednesday, September 27, 2006 11:06 AM
To: jQuery Discussion.
Subject: Re: [jQuery] Form plugin's serialize(): performance issues
Unfortunately, jQuery doesn't support the OR selector '|', otherwise
that'd work quite nicely. The problem is that I don't know how this
would work without using *, and filtering away what you don't need -
while still keeping the order of all the elements that you want.
If anyone has any ideas, I'm all ears.
--John
On 9/27/06, Matt Grimm [EMAIL PROTECTED] wrote:
I've run into a significant performance issue with the form plugin's
serialize method; not a bug per se, but definitely a show-stopper for
me. The problem is that I have a form with a select element, which has
around 250 options. The serialize method grabs *all* child elements of
the form before operating on any of them, like so:
$('*', this).each( ... );
This is awfully inefficient, especially considering each element type
is handled by name anyway in the following code. Perhaps it would be
best to define the top-level or containing elements first, then grab
just those (i.e., excluding OPTIONs):
var elems = ['INPUT', 'SELECT', 'TEXTAREA', ...] $(elems.join('|'),
this).each( ... );
So instead of looking through each OPTION for a selected property, the
parent SELECT could be checked for its selectedIndex property. Any
thoughts?
m.
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
--
John Resig
http://ejohn.org/
[EMAIL PROTECTED]
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Form plugin's serialize(): performance issues
Mike Alsup ha scritto: Believe it or not, make it a reverse for loop, it is even faster: Except that we want to process them in semantic order! :-) Hi, I read John and Mike pointed out the need to process form elements keeping their order. Can you explain why processing elements in semantic order is important? Thanks, Renato ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Form plugin's serialize(): performance issues
If you say jQuery doesn't support the OR selector '|', then I'm
confused. I have a form with one SELECT element and several INPUTs.
Check out the following results from Firebug:
$('INPUT', $('#myform')).length
6
$('INPUT|SELECT', $('#myform')).length
7
That's what I expected as a result.. can you explain?
Oh... well, I'll be:
if ( !t.indexOf(,) || !t.indexOf(|) ) {
Apparently I treat a | just like a , - which is odd and incorrect. I
must've added that a long time ago and forgot about it. The result of
each operator should be something like:
For ',' (AND): input, input, input, select
For '|' (OR): input, input, select, input
The problem is that doing an 'OR' search with the DOM is hard
(certainly not as easy as doing an AND). So, for now, I'd recommend
migrating your '|' usage to ',' - as it probably won't work as you'd
expect it to, for forever.
--John
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Form plugin's serialize(): performance issues
Can you explain why processing elements in semantic order is important? Two reasons: $(input | select).eq(0) This should access the first matched element of input or select - when the order isn't important, you'll never know which element will actually be first. It's important that the element is actually the first element in the document. Secondly, when serializing forms, the order of the elements that comes back is frequently important - having a different order can cause problems for certain applications. --John ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Form plugin's serialize(): performance issues
Can you explain why processing elements in semantic order is important? Hi Renato, The reasoning behind keeping the elements in semantic order is to have the form submit data to the server in EXACTLY the same order as it would if javascript were disabled. For many, this is unimportant, but some folks have server-side code with ordering dependencies. Mike ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Form plugin's serialize(): performance issues
Perhaps there should be a FastSerialize method, that doesn't guarantee semantic order, and uses every shortcut to cut down on dom-walking time? This way, the developer can choose whether to use the faster method, or the slower-but-correctly-ordered method. - Brian Can you explain why processing elements in semantic order is important? Two reasons: $(input | select).eq(0) This should access the first matched element of input or select - when the order isn't important, you'll never know which element will actually be first. It's important that the element is actually the first element in the document. Secondly, when serializing forms, the order of the elements that comes back is frequently important - having a different order can cause problems for certain applications. --John ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/ ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
