We do a fair amount of WebKit related work here at Crank. You rarely see our developers in the public eye because many of our ports to date have been to esoteric operating system, hardware platforms or custom graphics environments.
One of the areas we are frequently requested to assist in, is in the tailoring of a port to a particular set of performance contraints, usually CPU and memory usage. This is rarely straightforward as it involves an in-depth understanding of what trade-offs a customer is willing to make in terms of features and functionalities.
This week on the WebKit mailing list there was an interesting thread surrounding the 'leaking of memory' as perceived by a user who expected that if all the memory caches were turned off, that there should be no image resource maintained in memory. For WebKit, as it stands today, that is not a true statement. The discussion thread is a bit fragmented and the best way to follow it is to go here:
and search for the subject "Regarding cache memory leaks".
The comments are enlightening, and demonstrate just what kind of work is required in order to curb the active memory consumption of WebKit based products.
We've done this kind of customization a few times now and are hoping that we will shortly be able to launch an embedded friendly WebKit platform that uses Storyboard as the UI/browser framework.