[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Memory use (Was: Bug#18307: ...)
From:       Waldo Bastian <bastian () kde ! org>
Date:       2001-01-16 19:41:15
[Download RAW message or body]

On Tuesday 16 January 2001 11:29, Kuba Ober wrote:
> > > 3. There is not that much heap and static data in a single app as to
> > > make any problems with many separate instances (say 100 copies of
> > > konqueror), right? I mean, assuming that executable code and library
> > > code sharing indeed takes place. How much (heap+static+stack) data does
> > > konqueror allocate when a new empty window instance is opened? 16kb?
> > > 100kb? Even if
> >
> > Well, a new window in the same process doesn't take that much. However,
> > we need quite a bit of data for a new process.... menu-stuff, icons etc.
> > take quite a bit of memory.
>
> So here come another possibilities
>
> 1. What about linking constant data (say icons) as readonly stuff. This can
> be either done by explicitly linking binary data using the linker (would
> need to be implemented in the build process), or using the code (constant
> arrays - I wonder whether gcc marks them readonly)
> There's really no need for applications to have duplicates of same icons
> and similar stuff. I'd imagine that standard qt and Kde apps can live
> happily with compiled-in icons.
>
> 2. Using memory-mapped files.
> I wonder how portable memory-mapped files are, and how much overhead there
> is if you use them on non-paged systems. On flat-space systems (non-paged
> and/or non-segmented, say m68k embedded w/o mmu) the readonly memory-mapped
> files are (should be because that's trivial to implement) a form of shared
> memory. When you open them for read-only access OS assumes (should
> assume)that you won't modify the memory contents and just returns the
> pointer to the shared copy.

This is what ksycoca does, we fall back to simple file-reads if mmap isn't 
available.

I have been playing with the idea of caching icons this way as well, but it 
seems that reading e.g. a .png icon from disk is quite fast. I'm not 
completely sure, but I guess most icons are actually stored as pixmaps in the 
X server. In that case they don't take up much space in the application 
itself, so including them in the executable or mmaping them wouldn't make 
much of a difference. What would help is to share pixmaps between processes.

Ideas for a shared pixmaps / a pixmap server have been floating around for 
some time.

Cheers,
Waldo
-- 
bastian@kde.org | SuSE Labs KDE Developer | bastian@suse.com
 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]