ansaurus

Question

Answer 1

A:

Run your code in a profiler and see what it is actually doing. See where your time is spent. IE8 provides IE7 compatibility and a decent profiler included in its Developer Tools.

To do the profiling in IE7 directly you will have to mess around with Visual Web Developer or the debugger bundled with MS Office. More fooling around is necessary, but it is possible to get it to work. Every time I have needed to set this up on a new computer it has taken me an hour or more to figure out the magic incantation to make it work, but it is doable.

lambacck 2009-06-15 01:15:11

Well that wouldn't really help if his problem exists in IE7 but not IE8.

musicfreak 2009-06-15 01:16:18

Does the IE7 compatibility mode have the same speed profile as a native IE7? If so, profiling would be a great start.

Nosredna 2009-06-15 01:23:38

No, it just conforms to the way IE7 does things, but it definitely does not have the same speed.

musicfreak 2009-06-15 01:28:13

Profiling will still give you an idea of where you should start looking. Unfortunately the problem might be side effects of DOM manipulations. The amount of time it takes to say do inputbox.checked=true varies wildly between browsers (Opera seems to be particularly slow).

lambacck 2009-06-15 02:59:50

Answer 2

+2 A:

A couple off-the-wall suggestions...

Flash as coprocessor. If you have computationally expensive things to do, you can hand them off to Flash. The ActionScript is going to be faster than IE's lousy JS. However, be aware that if you transfer much data back and forth between JS and Flash, it's very slow.
Google Gears. You can speed things up with web workers. When you detect IE7, say that upgrading to IE8 or installing Google Gears will improve the experience.
Possibly Silverlight could be used as a coprocessor. I don't have experience with it, however.

Can you even tell what's slow? Is it when you touch the DOM?

Nosredna 2009-06-15 01:22:59

+1 to both suggestions, I didn't even think about Flash.

musicfreak 2009-06-15 01:28:57

Added a mention of Silverlight, although it's just a guess as to whether it would work.

Nosredna 2009-06-15 01:40:18

can't use silverlight due to same reason as above. I wish i could!

2009-06-15 02:13:42

the slowness I see is when carrying out actiosn on the page such as collasping sections

2009-06-15 02:14:30

Do you animate the collapses?

Nosredna 2009-06-15 02:17:40

no not at all...its not only that action thats just one that i knew people would know...its like any kind of event on the page

2009-06-15 02:22:00

i also haven't heard about the Flash idea, sounds feasible, and flash is everywhere. about Gears, I don't see how it could help, since the worker threads also use the same lousy JScript interpreter as explained here: http://groups.google.com/group/gears-users/browse_thread/thread/33ad4d515fb4a51b/a8c62c1fb4858ddd also saw your question here: http://ajaxian.com/archives/gears-03-released-and-google-io-videos-on-ajax-related-content-available

Javier 2009-06-15 02:28:59

But some people insist the workers do work because they're on a different thread. I'm not convinced the problems here are JS, though. Might be IE7's DOM handling.

Nosredna 2009-06-15 02:34:51

IE8 supports web workers?? I can't find any reference

Infinity 2010-03-05 18:51:03

Answer 3

A:

This is an excellent google tech talk video on javascript optimization by javascript guru Nicholas C. Zakas http://www.youtube.com/watch?v=mHtdZgou0qU

He advises you to use local variables to limit scope lookup, keep javascript css style changes to a minimum(change classes instead) and do them in batches if you have to to reduce browser re-rendering, and lots of other great tips :)

Charles Ma 2009-06-15 01:41:02

That's a great talk. I have Souders' first book. I'll have to get the new one.

Nosredna 2009-06-15 02:00:33

also check the YUI Teather: http://developer.yahoo.com/yui/theater/ there are talks about JS, AJAX, performance, style and philosophy of JS from Douglas Crockford, John Resig (jQuery), Nicholas Zakas, etc.

Javier 2009-06-15 02:35:25

Answer 4

A:

I kind of feel like maybe some of these answers might be missing the obvious.

What is the efficiency of the algorithm you are using? Linear? Logorithmic? exponential? It seems to me, that if it's the JAVASCRIPT that's getting slower, as the document gets larger, then it's the efficiency of YOUR code that's the problem, not MS's. IE javascript is slow, but what makes you so sure that it's specifically a problem with that browser? Do other javascript engines do okay with it?

Without knowing a single thing about what you're doing or how you're doing it, one way to go is to trade off memory usage for speed- Cache previous results, and other optimization strategies which you can find lying around if you read this book or that website about programming.

Another thing to keep in mind is that dom interaction is really slow. If you can reorganize your code to achieve the same thing, but with fewer manipulations in the dom, that will improve performance

Breton 2009-06-15 02:02:32

Yeah, we're just guessing without the code. My biggest problems in IE7 have been with animated visualizations (where I had to bring the target framerate down to 1/4 that of the other browsers) and anything that uses Canvas. Even IE8 doesn't support Canvas directly.

Nosredna 2009-06-15 02:07:47

I do have to do quite a bit of dom manipulation based on the user's interactions. I use the Telerik RadControls all over the page too which do alot of dom manipulation.

2009-06-15 02:16:48

so let me ask you this, if i had moved some of my dom manipulation intense actions to something like an iframe the number of dom elements would be dramactically smaller and therefore do you think it would be faster or even slower dealing with the iframe?>

2009-06-15 02:19:09

If you have a lot of DOM manipulations to do to a particular part of the tree, pull that out, do the work on it outside the DOM, then put the whole thing back.

Nosredna 2009-06-15 02:20:31

thats an intersting idea...can u do JQuery stuff on just strings tho?

2009-06-15 02:22:45

Here's an example in Mootools. The author says it's easy to port to jQuery... http://stackoverflow.com/questions/987889/speeding-up-jquery-empty-or-replacewith-functions-when-dealing-with-large-dom

Nosredna 2009-06-15 02:26:08

any thoughts about the iframe tho

2009-06-15 02:37:31

Might work. Worth a try. I'd love to know. :-)

Nosredna 2009-06-15 02:41:16

jQuery's clone() is used to move sections of the DOM around. Maybe you can work on the clone until you're ready to put it back.

Nosredna 2009-06-15 02:57:15

Mainly, when I refer to DOM manipulations, I'm referring to the number of times you touch any kind of dom element, on screen or off screen. I had this somewhat similar question in mind: http://stackoverflow.com/questions/895992/896012#896012 , Where that person is using jQuery to find elements every time through a loop, when he could have cached the first result. I can't make more specific suggestions since I don't see your code, but try and look for places where you're performing idempotent operations more often than you need to, or find ways to combine multiple operations into a single one.

Breton 2009-06-15 03:32:37

You might also keep in mind that a lot of performance is just perception. What exactly is it you see unfolding on screen that makes you feel like it's being too slow? Sometimes a solution is as simple as adding a progress bar, or moving the parsing and execution of the javascript until after the page has rendered, and CSS applied.

Breton 2009-06-15 03:35:11

"so let me ask you this, if i had moved some of my dom manipulation intense actions to something like an iframe the number of dom elements would be dramactically smaller and therefore do you think it would be faster or even slower dealing with the iframe?" just going on gut instinct, I don't think it would be faster, as an iframe is still part of the dom, and simply moving the location of the dom operations doesn't reduce the number of them.

Breton 2009-06-15 03:36:52

But it might make it *feel* faster by deferring the costly operations to a different thread, so the page can continue to render, unbothered.

Breton 2009-06-15 03:40:29

Answer 5

A:

Attach and detach events as needed and do not use behaviors. Also create threads to speed up UI using setTimeout and setInterval. I do this all the time to prevent IU choppiness.

nickyt 2009-06-17 17:43:37

Answer 6

A:

Some pretty regular gotchas pertain almost exclusively to the DOM, which is slow accross browsers. Try to user innerHTML wherever possible. It's not the standards-compliant way of doing things, but it is by far the fastest.

If you're looping through DOM elements using something like the following:

for (var i = 0; i < domNodes.length; i++) { ... }

Note that every time you request the length of a NodeList, a rather expensive lookup operation is performed. You're better off caching the length of the NodeList as follows:

for (var i = 0, il = domNodes.length; i < il; i++) { ... }

The performance improvements here are incredible. Robert Nyman did an interesting comparison of for loops. If you've never heard of this, the performance boost might surprise you.

Andrew Noyes 2009-06-17 17:50:38

ansaurus

tags:

views:

answers:

IE7 Javascript Performance...

related questions