[openbeos] Re: plug-ins [was Re: ShowImage "Mirror" Operations]
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Mon, 31 Jul 2006 11:25:42 +0200 CEST
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:
