[Development] Assistant WebKit/WebEngine support

[Simon Hausmann]

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.


Simon