Memory consumption: QtWebKit->compare(WebKit1, WebKit2, SystemMalloc, TCmalloc)

Last year I got a Nokia N9 on Qt Developer Days, it's a great mobile phone, I really like it, but I haven't published any memory measurement results about it yet. In my last post I did WebKit memory profiling on it with Valgrind, but it was all about heap usage. I think a number of persons are interested in the overall memory usage such as peak memory usage, the sizes of the used libraries, etc. During QtWebKit's life-cycle we switch from one library to another, usually because of performance considerations. In the past we do not take too much attention to memory consumption-related topics while switching between libraries, although it would be very vital to keep eye on this area as well.

War of allocators: TLSF in action

The main focus of my next experiment is yet another allocator called TLSF (Two-Level Segregate Fit). Based on the info published on its website, TLSF has bounded response time, efficient allocation methods which are fast enough, and it has efficient memory usage. Furthermore, the site promises quite good memory fragmentation values. Can it demonstrate all this inside WebKit?

War of allocators: hoard or hoards?

I found Emery Berger's allocator called hoard. Hoard's homepage holds out some promising general qualities (fast, scalable, and memory-efficient) about the allocator, do we need more than this? I tried out how it performs in WebKit.

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. :-)

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.

The effect of TCmalloc in the QtWebKit port - stage 1: Performance

Much time has passed since we started to work on the custom allocation framework with Paul Pedriana. The core of the solution (FastAllocBase class, bug #20422) was landed into the trunk half year ago.

Syndicate content