konqy preloading kills performance

[Dario Massarin]

On Thursday 16 December 2004 13:53, Lubos Lunak wrote:

>  Actually, my kernel (SUSE 2.6.8-24.3-default) has better documentation:
>
> Table 1-2: Contents of the statm files (as of 2.6.8-rc3)
> ...........................................................................
>... Field    Content
>  size     total program size (pages)            (same as VmSize in status)
>  resident size of memory portions (pages)       (same as VmRSS in status)
>  shared   number of pages that are shared       (i.e. backed by a file)
>  trs      number of pages that are 'code'       (not including libs;
> broken, includes data segment) lrs      number of pages of library         
>   (always 0 on 2.6)
>  drs      number of pages of data/stack         (including libs; broken,
>                                                         includes library
> text) dt       number of dirty pages                 (always 0 on 2.6)
> ...........................................................................
>...
>
>  This makes the mistake obvious - the size is in pages.

Yeah!!! We have the answer!!

>
> > mapped:   59780 KB writable/private: 26792 KB shared: 1072 KB
>
>  14944 * 4096 / 1024 ~= 59780

>  Doing arbitrary changes to thresholds to fix unknown problems is not a
> very good idea. But now that the problem is know, changes are needed of
> course.

Ok.

>  Exceeding the 8M threshold is actually trivial, after multiplying the
> current values by 4 - e.g. viewing dot.kde.org does the job. The /proc
> method uses complete memory usage of the process, including shared memory
> taken by libraries etc. , and the initial increase is large. In fact the 8M
> threshold is almost reached even by just showing empty Konqueror window and
> closing it, it seems there's a lot of delayed initialization going on.

Yes. This is true. With an empty konqueror we have a memory increase of about 
6.4Mb.

>  I'll fix the usage computation and backport it, and I'll change the
> threshold to let's say 20M, in order to avoid the current real threshold of
> 64M. 

Ok. Thanks.

> If somebody feels like improving it e.g. to detect all memory 
> available and keep this low limit only for old machines, feel free to.

Yes, this still remains a good solution, but with this fix the problem seems a 
lot smaller :-)

Thanks a lot. 

Cheers,
	Dario