Home

memory

War of allocators: The QtLauncher's coast

After I benchmarked JavaScriptCore with our new participant called DLmalloc, it has been suggested to test it with QtLauncher also. I compiled DLmalloc in thread-safe mode (USE_LOCKS=1), so it became capable to serve WebCore's memory requests. Perhaps, another solution could have been to turn off every use of threads in QtLauncher/WebCore, but I think this would be a lucky approach...

War of allocators in JavaScriptCore: another participant

There are a lot of custom allocators in the world, so let's try another promising one, called DLmalloc. It was made by Doug Lea. I've put DLmalloc into JavaScriptCore with the help of the custom allocation framework. I tested DLmalloc only in JavaScriptCore, because it didn't work well with QtWebKit's multi-threaded features. The measurements have been made with QtWebKit, running on x86 Debian-Lenny.

 

War of allocators: The field of Workers

Since, two of our tested allocators - TCmalloc, JEmalloc - benefit in multi-threaded environment, I did some benchmark which uses threading effectively. I run 2 instances of each popular benchmarks simultaneously with the help of JavaScript workers. I benchmarked on Linux-Qt port of WebKit and used official r54475 revision. All measurements were running in QtLauncher and did minimal painting only.

War of allocators in JavaScriptCore

JEmalloc is a highly scalable memory allocator made by Jason Evans. This is the default allocator of the FreeBSD operating system and Firefox's Linux/Windows versions, but how does it perform in WebKit?

The sounds of TCmalloc in QtLauncher

It took a while but now I'm happy to announce that all core classes are inherited from FastAllocBase in WebCore. Further the previous changes in JavaScriptCore, by now almost the whole world is a subclass of FastAllocBase. :-)

Detailed memory consumption of some popular sites. Poor good old malloc, everyone's beast of burden.

It is time to try out my new freya tool. Only some web-sites and a fresh Qt (4.6.0) and QtWebKit (r51481) are needed. The values are peak memory consumptions, which is not necessary the best choice (since the sum of their total value is greater than the peak memory consumption), but at least we can see the memory hungry parts of QtWebKit.

A new tool to extract meaningful memory consumption values. Valgrind shines again.

Every program allocates memory, regardless of its size. Reducing it is an important task and an eternal struggle. Using advanced memory profiling tools, it is easy to see that the most memory is consumed by ... hash tables, vectors, unicode strings, mmaped memory regions, etc. But is THIS what you are interested in? Isn't it would be better to know how much memory consumed by WebCore, JavaScriptCore, Qt, or by a particular component, like WebCore/css?

The effect of TCmalloc in the QtWebKit port - stage 2: Memory consumption

As I mentioned, there is a reverse of a medal, so now let's see how enabling TCmalloc on the QtWebKit port's JavaScriptCore engine effects memory consumption.

Memory consumption: scratching the surface

  • Posted by zoltan.horvath at 05/13/2009 - 11:06

On Linux platform, WebKit doesn't provide us with tools/scripts for investigating memory consumption, although this topic might be almost as important as runtime performance. For example, just think of an embedded environment where memory is limited and the usage of memory has an impact on the device's power consumption.

Disabling the cache

  • Posted by balazs.kelemen at 04/28/2009 - 15:24

A goal of mine is to decrease and limit the memory usage of WebKit. In embedded environments, memory can be even more important than performance. I was interested how can the memory consumption be lowered with the functionality already present in WebKit's code base, i.e., without too much hacking of the code.

Syndicate content