What's Enlightenment doing for so long?

[Carsten Haitzler (The Rasterman)]

On Mon, 25 Aug 2008 10:57:49 +0100 Rui Miguel Silva Seabra <rms at 1407.org>
babbled:

> On Mon, Aug 25, 2008 at 12:06:07PM +1000, Carsten Haitzler wrote:
> > On Sun, 24 Aug 2008 14:33:22 +0100 Rui Miguel Silva Seabra <rms at 1407.org>
> > babbled:
> > 
> > > After de "Booting" part with a progress report, we get the Boot's again.
> > > 
> > > But I already can ssh into the Freerunner, and doing a top I see that
> > > it's enlightenment who's taking a bloody huge time loading up. Feels
> > > like about half of the booting time.
> > > 
> > > I wonder what could be done to speed it up...
> > 
> > it's
> > 1. loading config
> > 2. connecting to x and querying stuff, settign up atoms and properties
> > 3. loading data (theme) files
> > 4. scanning disk for .desktop files (as these are all the applications)
> > 5. scanning fonts for use
> > 6. setting up ipc
> > 7. testing runtime breakages (eg you removed the png, jpeg or eet loaders
> > from evas as they are runtime replacable modules)
> > 8. dbusinit and connect
> > 9. query some hal info (removable devices etc.)
> > 10. loading its own modules and letting them all do their init.
> > 
> > also note it only gets a fraction of the resources - qpe (and its tools like
> > mediaserver and quicklancher) all are fighting over cpu - the animated
> > splash uses a bit too, so as such it's left with about 15-20% of the cpu at
> > least for itself to do its init. the splash of course could be simpler and
> > use less cpu. no plash and u'd just have a blank screen for a while (its a
> > config option of course).
> 
> Thank you,
> 
> My point wasn't to criticize but to check out what could be done to speed up
> this component in order to have a smaller boot time, and with a different
> screen.

well boot has 2 phases. system boot then gui boot. system boot is the first
"boots" screen. this is exquisite doing the gui - it is a bootloader splash app
that uses EFL. so the theme is a .edj file - once you figure out edje... it
works pretty much the same everywhere. you can go completely wild here -
bootsplash is pretty flexible in terms of how wild a ui you can come up with
(from mimicking the old moko orange boot to pretty much any boot screen out
there to something new).

the 2nd boot splash (after the blank which is x starting up) is e's init splash
screen. it uses this (if turned on) to keep you amused while e does the above
and more. again - edj file. theme customising again.

> Since the resources are quite low in comparison to a modern computer
> maybe it needs some low-resource-computer specific optimizations.

well the less it does.. the less is devoted to something other than
necessities. so simpler animations at a lower framerate for example. (so for
example just an tiny icon blinking on/off every 0.5 seconds would use much less
than that bar bouncing about at 30fps). otherwise following freedesktop.org
standards does hurt performance a lot - having to scan for .desktop files and
hunt and scan for icons for them... :(

> I'm actually considering studying e's libraries in order to create some
> replacements for the most common applications.
> 
> I think it's quite intolerable that in idle the main applications (at
> least) aren't near instantaneous, and if e's the way to go, then e-like
> apps should be written.

trust me. i've looked at what e's doing on start. it should really take a few
seconds (6 or so) at most to start up all of e. that's what i clock it at when
it's not competing with qpe or anything else with init splash removed and any
data it needs cached in disk cache). init will slow it down a little but keep
you amused while it does its stuff. so it's worth it - but making the init
splash simpler (it a small spinning icon in the corner, not a big bar bouncing
about) would help. otherwise there is not a lot that can be done to really make
big headway into e's startup there. i have regularly sat down with it and gone
over it to optimise. it really needs a deep understanding of whats going on to
do it without breaking anything.

btw - app startup is generally very fast - if the apps are in c. i clock in a
simple efl application at under 1 second (about 0.8) and a simple gtk app at
about 1.5 secs or so. so as such toolkit isnt much of an issue here in start
time. :) you are just going to have this kind of lag no matter what. lots of
libs get resolved for symbols for pretty much any app using enough gui libs -
there is x setup (connect, query for info etc.) and likely loading in of data
from disk (icons, maybe fonts etc.) so... you're not going to really do much
better i think just using efl. it doesn't matter much really. efl just tends to
do a little less on init, but generally is more data-driven from files on disk
(eg .edj files) and so needs to load these in too.

-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>