KIconLoader Optimization Idea

[Roger Larsson]

On Tuesday 07 June 2005 01.29, Simon Perreault wrote:
> On June 6, 2005 15:11, Alexander Neundorf wrote:
> > If you communicate via a socket you have a protocol which has to be
> > interpreted, the data has to be serialized and deserialized and task
> > switches happen.
>
> Sure, but why is this slower than disk I/O? To me it seems that the task
> you described is CPU bound while the current situation is I/O bound, and I
> would guess that the CPU bound task should be faster.

This is what you need to do:
1. Find the correct icon (each user or even application can have their
   own set, and they should not be able to borrow from each other)
2. Read the correct icon from disk, effectively
3. Decompress the icon
4. Transfer the bitmap to X-server
5. Transfer the bitmap to graphic board
6. Garbage collect unused icons, both
    a) compressed
    b) bitmaps
   +) But don't garbage collect when there is space left! Starting, stopping
      followed by another start of the same application should not throw out
      the cached icon from memory.
7. Do not cache stuff never needed (only on demand) - relax this even more?

Because the Linux kernel will cache the files. It might be viewed as an
automatic icon server. Any implementation has to do better than it:
* Reentrant - several treads/processes can request data at the same time, user
   might have a SMP (multi core) computer.
* [1] Security, you can not view an icon/image you do not have read access to.
* [1] Filenames are hashed for fast search, even negative results if I
   remember correctly (file not found)
* [2] Optimises reads from disk, queues and reorders. Would probably do even
   better if several requests were submitted at the same time 
   [this is an interesting subject, how are icons placed on disk]
* [6a] Automatic garbage collection.
* [7] I think the kernel caches some possibly unneeded stuff, blocks close to
   requested ones...
* Stores png icons compressed (to save space :-), but probably wastes it again
  due to buffer sizes.