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

List:       kfm-devel
Subject:    Re: Startup time (RE: konqy listview configurability)
From:       Simon Hausmann <shaus () helios ! med ! Uni-Magdeburg ! DE>
Date:       2000-03-20 15:14:51
[Download RAW message or body]



On Mon, 20 Mar 2000, David Faure wrote:

> On Mon, Mar 20, 2000 at 03:13:57PM +0100, Simon Hausmann wrote:
> > 
> > I fear most time on startup is spend on resolving symbol references when
> > loading the shlib view components.
> > 
> > I think in 60% of all konqueror startup cases the user wants to see an
> > inode/directory resource, so what we could perhaps do is to specify
> > libkonqiconview, libkonqlistview, libkonqdirtree in the Makefile.am of the
> > konqueror binary?
> > (*duck* :-)
> 
> Ah ah ah - and you were the one that wanted to split this up 
> when we did it ! ;-)))

Yes, that's why I *ducked* :-))

> Hmm, konqueror is also designed to be a web browser. In this case
> one doesn't want the code of all the inode/directory views in memory.
> 
> Is it really slow to dl'open ? Argl, once more, no perfect solution.
> Either memory consuming, either time consuming...

Yes, I fully agree.

Seriously, I agree that the link-libkonqiconview-against-konqueror-binary
way is no solution.

I guess the "perfect" solution would be to start hacking the dynamic
linker.

I guess though that we cannot do that, and I guess that's why Waldo
introduced kdeinit :) .

However: Can the kdeinit approach help us when dlopening libs?
(it helps when starting "standard" kde apps which link against often used
libs, but isn't that different with shlib components?)


Did anyone investigate the possibilities of joining the gnu ld.so hacker
team? Is it realistic?

I remember that Rikkus once mentioned on IRC that he wanted to get his
hands (together with Njord/Charles) on starting hacking ld.so and adding a
global symbol caching system.

I'm clueless

Ciao,
 Simon

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