- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 27 Oct 2010 09:22:52 -0400
- To: Keean Schupke <keean@fry-it.com>
- CC: Jeremy Orlow <jorlow@chromium.org>, Nathan Kitchen <w3c@nathankitchen.com>, nathan@webr3.org, public-webapps@w3.org, Jonas Sicking <jonas@sicking.cc>, Arthur Barstow <art.barstow@nokia.com>
On 10/27/10 7:12 AM, Keean Schupke wrote: > Actually the problem with this is the internal memory usage by the > browser to have a single page with 5000 divs in a list, each of which > has a layout with say 20 elements, so about 100,000 elements. The memory > used by the browser for the DOM tree In 64-bit Gecko (the numbers are smaller in a 32-bit build) a <div> is 56 bytes. So 100,000 of them (and using 20 elements for layout is a _lot_ of elements, btw) is 5.6MB of RAM used. Your typical low-end device nowadays has 64MB of RAM, right? So if the above is all you're looking at you're more or less ok. And again, if you're using 20 elements for layout then you're probably doing it wrong. > and rendering This is a much bigger problem, in my experience. Gecko implements some XUL rendering classes that try to solve this problem by only creating rendering objects for the things that are visible in the viewport, subject to various limitations. We've been thinking about ways to try to generalize this to web content... > is the problem, so I don't think (correct me if I am wrong) the > Flyweight pattern can help. Browsers use exactly that pattern already to reduce the memory used by DOM and rendering. And the things we've been thinking about mentioned above also work similarly. > To get round this we only create enough divs to fill the screen, and > cycle them round by catching onscroll events. This is just about fast > enough - but was something I had to implement for our web developers as > a library due to the complexity. Right; the idea would be to move this sort of thing into the browser core. -Boris
Received on Wednesday, 27 October 2010 13:23:33 UTC