11

I'm currently debugging a ajax chat that just endlessly fills the page with DOM-elements. If you have a chat going for like 3 hours you will end up with god nows how many thousands of DOM-nodes.

What are the problems related to extreme DOM Usage?

Is it possible that the UI becomes totally unresponsive (especially in Internet Explorer)?

(And related to this question is off course the solution, If there are any other solutions other than manual garbage collection and removal of dom nodes.)

Aaron Butacov
  • 32,415
  • 8
  • 47
  • 61
Jens
  • 304
  • 1
  • 2
  • 10
  • 1
    Are you experiencing problems or just speaking theoretically? If so, can you give an url or at least some more detail on what kind of slowdowns do you see (when attaching new nodes, when scrolling, ajax events, etc). You should try http://www.dynatrace.com/en/ – gblazex Dec 06 '10 at 13:36

3 Answers3

11

Most modern browser should be able to deal pretty well with huge DOM trees. And "most" usually doesn't include IE.

So yes, your browser can become unresponsive (because it needs too much RAM -> swapping) or because it's renderer is just overwhelmed.

The standard solution is to drop elements, say after the page has 10'000 lines worth of chat. Even 100'000 lines shouldn't be a big problem. But I'd start to feel uneasy for numbers much larger than that (say millions of lines).

[EDIT] Another problem is memory leaks. Even though JS uses garbage collection, if you make a mistake in your code and keep references to deleted DOM elements in global variables (or objects references from a global variable), you can run out of memory even though the page itself contains only a few thousand elements.

Aaron Digulla
  • 321,842
  • 108
  • 597
  • 820
  • Thanks. It's always hard to know how many dom-elements the browser can handle, but I agree that it isn't a good idea at all not to have a limit on the number of chat lines displayed in a chat session. A better solution is to have some kind of history view. Because I can't rebuild the whole thing some leeks are hard to "post-fix", but I've added some manual garbage collection. – Jens Dec 06 '10 at 12:53
11

Just having lots of DOM nodes shouldn't be much of an issue (unless the client is short on RAM); however, manipulating lots of DOM nodes will be pretty slow. For example, looping through a group of elements and changing the background color of each is fine if you're doing this to 100 elements, but may take a while if you're doing it on 100,000. Also, some old browsers have problems when working with a huge DOM tree--for example, scrolling through a table with hundreds of thousands of rows may be unacceptably slow.

A good solution to this is to buffer the view. Basically, you only show the elements that are visible on the screen at any given moment, and when the user scrolls, you remove the elements that get hidden, and show the ones that get revealed. This way, the number of DOM nodes in the tree is relatively constant, but you don't really lose anything.

Another similar solution to this is to implement a cap on the number of messages that are shown at any given time. This way, any messages past, say, 100 get removed, and to see them you need to click a button or link that shows more. This is sort of what Facebook does with their profiles, if you need a reference.

Sasha Chedygov
  • 127,549
  • 26
  • 102
  • 115
0

Problems with extreme DOM usage can boil down to performance. DOM scripting is very expensive, so constantly accessing and manipulating the DOM can result in a poor performance (and user experience), particularly when the number of elements becomes very large.

Consider HTML collections such as document.getElementsByTagName('div'), for example. This is a query against the document and it will be reexecuted every time up-to-date information is required, such as the collection's length. This could lead to inefficiencies. The worst cases will occur when accessing and manipulating collections inside loops.

There are many considerations and examples, but like anything it depends on the application.

Chocula
  • 1,946
  • 1
  • 16
  • 21