jQuery performance in IE7
Antranig Basman
antranig at caret.cam.ac.uk
Wed Jan 28 17:00:15 UTC 2009
To follow on from my earlier post.... the string manipulation is
highly unlikely to be a performance bottleneck. On the other hand,
you have many long strings of operations like this:
ui.item.parents('.itemTableBlock').eq(0).children('.itemRowBlock').filter(':visible').each(function()
{
etc.
It is wise to bear in mind that jQuery is not "magic" - it is a highly
convenient way of expressing DOM searches and scans, but in most
cases it has no "magic" means of making them any faster than they
would be if you did them yourself. jQuery "looks like" a pretty
funky functional programming language, but it has the performance
characteristics of a standard procedural one - it only has access
to the same DOM methods that you do.
So, these frequent calls to parents, children, filter, etc. are causing enormous expense
at frequent DOM scans - it would be wise to precompute the DOM nodes that you are
interested in just once and not perform a fresh jQuery for every expression you want to
evaluate.
What I suggest is that you apply the firebug profiler to discover
which are the really expensive function calls in your source -
although this will probably require you to refactor your code
somewhat so that each operation corresponds to some kind of named
function rather than endlessly cascading nested "$.ajax" calls :P
Since Firebug typically gets fairly confused by big nests of
anonymous functions. Although FF3 is very much faster than IE,
it should be sufficient to give you a sense where the specific
problems lie.
Another idea would be to test in FF2 whose performance
characteristics are a lot more similar to IE7, and whose Firebug
implementation actually works somewhat better than the newer
version.
Come back to the list if you need any hints on running multiple
versions of Firefox on the same machine - the key step is to
set the environment variable MOZ_NO_REMOTE = 1.
Cheers,
Antranig.
Lovemore Nalube wrote:
>
> Hey Colin,
>
> Here's the actual code:
> https://source.sakaiproject.org/contrib/uct/evaluation-pilot08-UI/tool/src/webapp/content/js/reorderUtils.js.
>
> ************************
> Lovemore Nalube
> Online Learning Environments Developer
> Centre for Educational Technology
> University of Cape Town
> www.cet.uct.ac.za
>
> /* Work Email: lovemore.nalube at uct.ac.za
> /* Cell: 076 186 1244
> /* GTalk: lovenalube at gmail.com
>
> On Tue, Jan 27, 2009 at 6:28 PM, Colin Clark <colin.clark at utoronto.ca> wrote:
>
> Lovemore,
>
> On 27-Jan-09, at 2:15 AM, Lovemore Nalube wrote:
>
> I've reached a stage in which the preliminary phase nears
> completion, however when testing the UI in IE7, there is a huge
> performance overhead. FF3 seems to hold the load quite easily. In a
> nutshell what freezes the browser is trying to filter through a
> response object to get elements that exist within and then show
> these on the UI. Has anyone ever had issues with jQuery
> performance/freezing the browser like this?
>
> I invite you to checkout the code at
> https://source.sakaiproject.org/contrib/uct/evaluation-pilot08-UI.
> The page with the new UI is Evaluations dashboard > My Templates >
> Edit Template
>
> Do you have a link to the specific JavaScript source code that you're seeing
> the problem in? We can probably lend a hand in optimizing your implementation.
>
> Colin
>
> ---
> Colin Clark
> Technical Lead, Fluid Project
> Adaptive Technology Resource Centre, University of Toronto
> http://fluidproject.org
>
> --------------------------------------------------------------------------------
> _______________________________________________________
> fluid-talk mailing list - fluid-talk at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-talk
More information about the fluid-talk
mailing list