Re: What's Enlightenment doing for so long?
On Tue, 26 Aug 2008 17:12:09 +0200 Fabian Henze <[EMAIL PROTECTED]> 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) <[EMAIL PROTECTED]> ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What's Enlightenment doing for so long?
> 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? > 9. query some hal info (removable devices etc.) maybe this can be done after the e start? 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. Fabian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What's Enlightenment doing for so long?
On Mon, 25 Aug 2008 10:57:49 +0100 Rui Miguel Silva Seabra <[EMAIL PROTECTED]> 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 <[EMAIL > > PROTECTED]> > > 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) <[EMAIL PROTECTED]> ___ Openmoko community mailing list community@lists.openmoko.org http://lists.open
Re: What's Enlightenment doing for so long?
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 <[EMAIL PROTECTED]> > 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. Since the resources are quite low in comparison to a modern computer maybe it needs some low-resource-computer specific optimizations. 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. Rui -- Or not. Today is Boomtime, the 18th day of Bureaucracy in the YOLD 3174 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What's Enlightenment doing for so long?
On Sun, 24 Aug 2008 14:33:22 +0100 Rui Miguel Silva Seabra <[EMAIL PROTECTED]> 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). -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
What's Enlightenment doing for so long?
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... Rui -- Kallisti! Today is Sweetmorn, the 17th day of Bureaucracy in the YOLD 3174 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
