[openbeos] Re: plug-ins [was Re: ShowImage "Mirror" Operations]

Stephan Assmus <superstippi@xxxxxx> wrote (in April, if you didn't 
remember :-)):
> > almost no matter how big the app is; the
> > parts that aren't used in an application are only loaded on-demand,
> > they never get loaded if the functionality is never used (same for
> > libraries).
> Because of virtual memory, mapping the executable and lazy loading? 
> Interesting. Is it true that putting all the GUI creation code into 
> one 
> place in the executable helps application launch time then? By pure 
> laziness, WonderBrush happens to have the GUI creation code for its 
> main 
> window in one object file. Is this actually good for performance 
> then? Or 
> is the linker optimizing stuff and shuffling things around according 
> to 
> execution path?

The application is linked before it is run, as we don't have 
implemented lazy linking yet, other than that, yes, that could help 
having it loaded faster.

> And another question: Does BeOS use lazy loading or is this a Haiku 
> thing? 
> I have noticed that on Haiku, when I use a tool in WonderBrush the 
> first 
> time, there can be a short delay and some disk activity. Is this the 
> effect 
> of lazy loading? I wouldn't mind if there was a process that kept 
> loading 
> the app in the background to fill the virtual mapping so the chances 
> of 
> seeing this delay become less likely.

Right now, Haiku loads single pages on a page fault, and that's far 
from optimal. When we reduce the "resolution" there, I'm sure the delay 
will already be reduced noticeably.
Furthermore, a prefetching algorithm in the background is planned to be 
there as well, as long as there is enough memory left :-)

> > I think
> > Refraction is just poorly designed, especially in BeOS with its 32 
> > MB
> > system wide add-on limit (but even without it).
> At least it should be usable when all plugins are removed. "Non-
> optional 
> plugin" defeats the purpose of "plugin". Plugins should be either for 
> making it possible to extend the app by third parties, or for the 
> user to 
> be able to remove unused stuff (like from the interface).

Exactly my opinion :-)
They can be handled identically internally, but that shouldn't be taken 
to the extreme in that required parts of the application are exported 
as an add-on.

Bye,
   Axel.

Other related posts: