[haiku-development] Re: Do optional packages need to include everything they do?
- From: Stephan Assmus <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 31 Aug 2009 19:02:17 +0200
Hi,
On 2009-08-31 at 17:42:17 [+0200], Michael Lotz <mmlr@xxxxxxxx> wrote:
> > Ok, I am measured the speed of certain stages (MM:SS):
> >
> > * time to rocket icon lighting up: 00:15
>
> Mostly burst read of the tgz boot archive, unzipping and running stuff
> from memory, some loading of additional modules after finding boot
> volume, so not problematic.
>
> > * time from rocket item lighting up to blue desktop 04:10 (!)
>
> Bootscript running, loading up some servers that are necessary and some
> that aren't. You won't get around the registrar, app_server and input_
> server. These load the servers, the libraries they use and cause modules
> to get loaded (graphics, input drivers). And there is also syslog_
> daemon, debug_server and net_server, which aren't necessary for the
> installer. If you remove these, or rather move these past the invokation
> of the CD bootscript, you should see quite a drop there. Note that the
> net_server is launched before the app_server right now.
>
> > * time to alert 00:16
>
> That should be mostly only the input_server starting up, as that one is
> launched by the app_server, so possibly after the blue desktop becomes
> visible.
>
> > * time to Installer note 00:38
>
> That should really only be the Installer loading plus any additional
> library not in memory by now.
>
> > * time to Installer main window 00:14
>
> I wouldn't really know why this takes so long, maybe scanning disks and
> loading of the corresponding modules delays this one.
>
> > I have an idea how I can optimize some of these...
>
> You can't really except for (re-)moving the non-necessary servers. Maybe
> reducing parallel access could help, but really after the app_ server
> launch there shouldn't really be too much parallel going on. I'm
> currently looking through the kernel to check a few problematic places
> (i.e. where large reads are split up into page wise reads).
The servers are launched into the background, which means the shell is
forked and the runtime_loader runs in another thread. By inserting sleeps
after launching critical servers (I'm currently doing this only when the
medium is read-only), I could already reduce the bootscript time from 4
minutes down to 30 some seconds. The parallel access is really the worst of
it because of all the seeks. This is obvious from just listening to the
drive. What you say about page-wise reads may contribute to the fact that
the drive does not appear to run at full speed (I recall it spinning *much*
faster), even when there is only a single thread doing sequential reads
(Installer copy process later on).
The areas I would like to optimize most are the bootscript time and the
delay between showing the alert window until all strings in the alert are
finally rendered (more than half a minute).
Best regards,
-Stephan
Other related posts:
