What's Enlightenment doing for so long?

[Carsten Haitzler (The Rasterman)]

On Tue, 26 Aug 2008 17:12:09 +0200 Fabian Henze <CC.Fan at gmx.de> babbled:

> > 4. scanning disk for .desktop files (as these are all the applications)
> > 5. scanning fonts for use
> 
> Isn't it possible to cache stuff like this in just one file? So e can start 
> using the cache and check for new .desktop files or fonts afterwards?

yes. but that cache hasn't been done as part of efreet - it's a cleanroom
implementation of the fdo standards as per their specs. it doesnt do much in
the way of trying to be too fancy. this would help though and remove the async
scan - or be able to defer the async scan until much later (once init is over
and stuff is idle).

> > 9. query some hal info (removable devices etc.)
> 
> maybe this can be done after the e start?

it kicks off some of it on init - it's async after that. check e;'s stdout
(well change login scripts to write it to a file). it benchmarks its own init
dumping a whole init+timestamp log. you do miss the first bit until it starts
logging - once it hits mainloop it's now in async land and everything is
deferred in async processes, timers, other daemons etc.

> On Mon, 25. Aug 2008 12:53:17 Carsten Haitzler wrote:
> > 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.
> 
> In my opinion 1 second is pretty slow and afaik people get annoyed if
> anything (interactive) takes more than 0.5 seconds. What about using LDFLAGS
> to compile the programs (dont know if this is already used). or precaching 
> commonly used applications like the Dialer, the SMS app or the contact list.

the 1 second is with everything cached - ie run it once, then again. you'll be
slower if more needs to be paged off disk. the way you can win is simply avoid
doign the whole exec and init N times. that is why e uses modules for a lot -
they are .so's dlopen()ed. so they basically biggyback all the init work e
already did for itself and so can extend e and add functionality - pretty much
anything they like, BUT... you pay a stability price. as its the same process -
you can crash the wm if your module is bad (then again a crash simply gets you
a white box asking you to restart or exit... which isn't the end of things).

this tends to cut a huge chunk off getting something up. either that or
starting all these apps on "login" (or boot or whatever you wish to call it),
and so the processes float about all the time idle until needed then pop up
their windows (which they have already prepared and populated with widgets
etc.).

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