4

I have developed a web site using JQuery and a lot of drag-and-drop elements which is working pretty well.

Nevertheless, on IE9 and when a lot of drag and drop elements are dynamically loaded (using .load()) and displayed, the browser is always consuming a small charge of CPU (~10%) (for refreshing?) even if nothing is done by the user for a long time without touch the mouse or scroll on the page.

I don't have any timer, and the behaviour on Chrome and Safari is OK.

Here is the context and what I discovered after my tests:

Context

In my main web page, I load the user views into a div using a load() function. The loaded views contain several containers with draggable elements. These containers are droppables and are refreshing after each drop event using also a load() function.

  1. If I insert 50 <br> tags in first in my web page, the graphic elements are not displayed without scroling in my page : my CPU utilization = 0%
  2. When I scroll to display only the half of my view containing the graphic elements, my CPU utilization = 10%
  3. When all my graphic elements are displayed : my CPU utilization = 20%
  4. When I reduce my windows size : my CPU utilization decrease according to the window size

Anyone could explain why? Give me an advice? Is it due to a lot of JQuery events? Any solution to spy which part of my code is taking CPU resource?

Any advice are welcome!

Edit

When I remove all JQuery events in my loaded view (click, mouseover, ...) and all JQueryUI elements declaration (.draggable(), .droppable()) the CPU utilization is still here.

But keep in mind that the view is always loaded dynamically using .load() function. FYI, I tried also to load my view with $.post().

I tried this morning with the new JQuery version 1.8.0 and JQueryUI 1.8.22 but this doesn't change anything.

sdespont
  • 13,915
  • 9
  • 56
  • 97

3 Answers3

3

jQuery uses a timer to manage animations. Every 13ms the timer runs.

You can download development jquery code, look for "interval: 13" and change it to, for example, interval: 150.

EDIT

From JQuery 1.4.3, the jQuery.fx.interval property can be manipulated to adjust the number of frames per second at which animations will run. The default is 13 milliseconds.

http://api.jquery.com/jQuery.fx.interval/

sdespont
  • 13,915
  • 9
  • 56
  • 97
user1154664
  • 1,392
  • 13
  • 11
  • Maybe he is looking for a bug in IE9. I wonder if Bouillou even tried it. I'm only trying to provide for a solution that already helped me once. – user1154664 Aug 06 '12 at 17:56
  • 1
    Sounded odd to modify JQuery source code. But, after spending time digging a bit, your solution is not a bad idea, but doesn't work for me. BTW, the right way to change this value : http://api.jquery.com/jQuery.fx.interval/ – sdespont Aug 07 '12 at 04:48
  • This may not help - but I know a good way to avoid bugs in IE using those libraries. ` – TheBlackBenzKid Aug 07 '12 at 11:26
  • Thanks for your suggestion, but it doesn't change anything in my case – sdespont Aug 08 '12 at 05:30
  • @TheBlackBenzKid I downvoted because the timer doesn't run when there are no jQuery animations on the screen. And when there *are* jQuery animations on the screen, it's hardly the timer that takes up CPU... I think the OP would have mentioned that he is having animations on the screen if that was the case, and in that case it would have been obvious why CPU is being used. – Esailija Aug 13 '12 at 11:53
2

You should profile your website in Internet Explorer - that'll give you a start as to where the CPU usage is going. (You asked for a tool.)

Vaughan Hilts
  • 2,839
  • 1
  • 20
  • 39
1

This may not be your case because I don't know if your're using Sortable or not but;

I had a similar issue with IE when I was using JQueryUI Sortable to handle the drag and drop. I had multiple UL elements on the page each with several LI elements and I was dragging and dropping between the various UL elements.

I did most of my development in Chrome and this was fine. When I switched over to IE for some testing the result was as you described.

It happened that during the development I had at some point specified both the 'connectWith' option (so I could drag selected elements from one to the another) and the 'items' option (so I could say which items inside the element should be sortable).

Now when I debugged through the source for JQuery UI, it does quite a lot of DOM manipulation under the covers such as removing and inserting nodes and binding various events and so forth. It turns out that when I had both the options I mentioned above set in the code JQuery UI did some sort of loop in a loop in a loop type of stuff and the number of times it set the position and style of the same element was (Items count * ConnetWith Count).

I had some styling in CSS to deal with (non-scrolling header, footer, and sidebar menu) and as JQuery UI manipulated the nodes it caused the browser to perform layout and recalculate style requests causing the CSS to be re-applied. The more elements I had visible on a page the more that needed to be laid out and styled. This can become an issue on IE when it has lots of inserting to do, such as with large number of rows in tables, but most of the time its not that noticeable. However coupled this with the almost exponentially increase in layout requests caused by JQuery UI processing / looping and I had a real issue on IE. I was working with a 1920 x 1080 screen so it was taking around 40 seconds on a fast machine before the CPU stopped going crazy. On other browsers it was only there for about a second or so.

Altering the styles of the header, footer and sidebar helped. But more importantly for me when I removed the 'Items' option from the code casing the style update loops to drop significantly the CPU only blipped for a short while and then went back to 0-1%.

Code Uniquely
  • 6,356
  • 4
  • 30
  • 40
  • Thank you very much for your well documented answer (+1)! Unfortunately, I don't use JQueryUI sortables elements. But your comment gives me more new way to explore in order to understand where my problem comes from. – sdespont Aug 10 '12 at 18:06