[Development] Assistant WebKit/WebEngine support

Eike Ziller Eike.Ziller at qt.io
Fri Jun 28 07:38:47 CEST 2019



> On Jun 27, 2019, at 16:55, Simon Hausmann <Simon.Hausmann at qt.io> wrote:
> 
> 
> Am 26.06.19 um 14:44 schrieb Kirill Burtsev:
>> Hi,
>> 
>> sorry, but that is not a right way to assess thing like memory consumption.
>> 
>> Windows shows in a task manager just private memory (can not be used
>> by other processes) usage for process. And that is really takes 15-20 Mb
>> but just for separate renderer process. Main process (in case for example
>> simplebrowser or minimal) needs around 30Mb of its own private memory
>> and +5Mb for every renderer process (basically page by default).
> 
> 
> You're right, I did not account for the qt creator process. Here's what 
> I see when starting a blank creator and loading the QWidget 
> documentation (that was a famous test-case when we developed QTextDocument):
> 
> 
>     * When using QTextBrowser, the creator process takes about 91 MB of RAM
> 
>     * When using QWebEngine, the creator process grows to 109 MB and 25 
> MB of private RAM for the web engine process.
> 
> 
> That's an overhead of 43 MB of RAM for showing the QWidget reference 
> documentation compared to QTextBrowser.
> 
> 
>> And there is also shared memory for all these processes (library itself,
>> which is over 100Mb for webengine, and other resources): 40Mb for main
>> process itself and then it goes to 80-90 with spawned rendereres. One can
>> see all these numbers inside extended columns for shared/private/workingset
>> memory inside detailed tab of a 'Task Manager', 'Resource Monitor' builtin
>> tools or simple ProcessHacker guitool for Windows.
> 
> 
> I'm aware of shared memory, and I'm deliberately excluding it. The bulk 
> of the shared pages are mapped from disk (DLLs) and can be discarded by 
> the kernel when for example the doc view is not visible in creator and 
> the kernel is low on memory (like when compiling). It's indeed the 
> private memory that hurts the users and that would have to be swapped to 
> disk in case of shortages.
> 
> 
>> So, for example, in case of offline html version of cppreference doc for c++:
>> https://en.cppreference.com/w/Cppreference:Archives
>> with 6 pages opened for basic_ostream it takes about this amount of memory:
>> 30 + 6 * 5 + 15 * 6 + 80 = 230Mb
> 
> Isn't counting for 6 open pages a bit of an unrealistic scenario? In 
> creator typically there's only one page of documentation visible at a time.

A common number of open pages if you do not do anything special is 3, as I wrote in my mail where I did my own assessment of ~70MB per open page on macOS.
Context help + Help mode + external window.

But we _do_ have the feature of opening new “tabs” in help mode, and these are restored at Qt Creator startup,
so it is actually not unrealistic to assume that people have more than 3 viewer instances at the same time.

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.ziller at qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B



More information about the Development mailing list