Re: KIconLoader Optimization Idea

Simon Perreault said:
> Maybe instead you could write a simple socket-based daemon. Protocol:
> client
> opens socket, writes null-terminated icon filename. Server accepts
> connections, uses cache to retrieve data, writes data on socket, closes
> socket. My guess is that the socket overhead will be negligible compared
> to
> the amount of time saved by using the cache. Also you could use a select()
> loop so that other queries could be satisfied while there is a cache miss.

Another option that might be worth pursueing (but is very difficult to
write reliably!) is to do all file I/O with icons in a thread. The app can
then continue to start up, assuming I/O itself is not the bottleneck. (And
if it is, then shared memory or anything else won't help much. After all,
if the shared cache misses the file you still need disk I/O, and if the
shared cache has the file then chances are that the kernel's file cache
also still holds the icon.

Last, any shared solution has the problem that locating icons is dependent
on KStandardDirs, and applications can influence what's there. So shared
solutions have to care about different clients using different resource
dirs, or different search order.

-- 
Martijn