Skip to main content

Bug Tracker

Side navigation

#7504 closed bug (invalid)

Opened November 13, 2010 10:26PM UTC

Closed November 13, 2010 11:12PM UTC

Last modified November 20, 2010 01:10AM UTC

Very slow selector in jQuery > 1.4.2

Reported by: ktecho@ktecho.com Owned by:
Priority: undecided Milestone: 1.5
Component: unfiled Version: 1.4.4
Keywords: Cc:
Blocked by: Blocking:
Description

I was using jQuery 1.4.2 to develop a very big and complex form where I must show and hide some fields between 3000+ elements. I have used previous versions as well, but 1.4.2 is the latest one to work ok. When 1.4.3 was released, I was very excited with the speed improvements shown in the jquery blog, as iterating through 3000 fields is sometimes a bit slow, but when I tried 1.4.3 I realized that it's a lot slower (some order of magnitude, or like 5 - 7 times slower).

The browser I have to use (it's used in the client PCs) is IE7, and with 1.4.3 (and 1.4.4) IE7 show 4 or 5 times the message 'Script is taking too much time, do you want to cancel it?'

I'm going to describe how the elements are and how I'm iterating them:

This is a common element:


<tr tab="ta_1" dim="en_A,re_V,se_2,tsk" id_col="AVNSEG_SAR_MEMBER" style="display: none;">

[...]

A lot of table info... links and a form element (textarea, input, etc.)

</tr>


This is an example selector used to show and hide groups of elements:


var tabCache = $(tabCacheGet(1));

$(tabCache).filter(

'[dim^=en_A][dim*=re_V],' +

'[dim^=en_G][dim*=re_G],' +

'[dim^=en_T][dim*=re_G],' +

'[dim^=en_G][dim*=re_I]'

).filter(selectorSeccionesActivadas).filter(':not([dim*=adv])').show();


The first filter parameter (tab="ta_1") is something like a super-group of elements that I cache to improve speed (it really saves time after the first search) using the function tabCacheGet(1). Once I have the supergroup of elements, I do the rest of the filtering with "filter" and the different 'dim' literals.

If you want for me to test some patch or something, I can do it, as speed difference is so big that I don't need a profiler or anything.

Thanks a lot.

Attachments (0)
Change History (3)

Changed November 13, 2010 11:12PM UTC by rwaldron comment:1

resolution: → invalid
status: newclosed

compounded filter statements using multiple attri bute selectors are going to perform very poorly. Please post on the jquery forums for help with selector performance.

Changed November 13, 2010 11:30PM UTC by ajpiano comment:2

Yes, jQuery could always be "faster" when it comes to element manipulation, but the performance roadblock here is not jQuery, it is the fundamental choice you are making to manipulate the style attribute of thousands of elements, instead of using CSS to impart the state. If you have a table with thousands of rows that need to be hid and shown conditionally, setting classes on the table - or even the rows - that set the display, rather than manipulating the style property, will perform considerably better.

There is not a really clear "bug" here, and this bug tracker is only for succint, duplicable issues that affect jQuery core. Selectors that cannot utilise QSA or other native methods, like getElementsByTagName, are inherently slower than those that do. Selectors that do regex tests, like [foo*=bar], are much slower than those that don't. Also, with attribute selectors, you'll pick up a perfgain - outside of IE - by quoting the attributes, so that that selector can be passed into QSA.

For what it's worth, there's no point in wrapping a jQuery object in another jQuery object. var tabCache = $(tabCacheGet(1)); tabCache.filter(expr);

The bottom line is this: while we understand that you are experiencing a performance bottleneck in your application, (and we've all been there), there is not a simple "fix" for "repeatedly filtering thousands and thousands of elements using nothing but nested attribute selectors and then manipulating their style attributes." As I've intimated thus far, the best "fix" in this situation is to understand what causes performance bottlenecks and how to refactor your application to avoid them. The support forums ( http://forum.jquery.com) and #jquery IRC channel on freenode, are a better venue for this type of discussion to continue than the bug tracker.

Thanks for your time and interest in improving jQuery!

Changed November 20, 2010 01:10AM UTC by anonymous comment:3

Well, I was not stating that jquery is slow executing my code. I was stating that with jQuery 1.4.2 or less, my selector works reasonably well. With 1.4.3 and 1.4.4 it's a lot slower. It lasts 5 or 6 times the amount of time to do the same traversing.