On Fri, 23 Sep 2005 22:26:44 +1000 David Seikel <[EMAIL PROTECTED]> babbled:
> Last whinge for today, honest. > > One of the big selling points for me about e17 is it's lightning quick > startup time. When using SuSE, I have to put up with three minute > booting time on my Athlon 3000+, so when logging onto KDE, having it > take thirty seconds to grind to a start just adds insult to injury. > e17 starts up almost as fast as a failsafe xterm, except when there are > lots of eaps. > > Running e17genmenu on a fully loaded SuSE Professional (hint, it is > distributed on a double layer DVD, there is LOTS of software) generates > lots of eap files. This is good, I have lots of apps, I want lots of > eaps. However, subsequent e17 startups then take forever, it seems to > spend a lot of time reading all those eaps. Cutting it down to just the > 40 or so eaps that I really need on a daily basis makes e17 startup in a > few seconds, a time I can live with. Everything else I have to start > the old fashioned way (typing the executables name). > > For this whinge I have a suggested fix, but first some background, and a > quick plug for one of my open source projects. > > I am building a Linux distro called My Linux > (http://my-linux.sourceforge.net/, not to be confused with > http://mylinux.sourceforge.net/, something I did in public once), > one of it's goals is to provide not bloated, quick versions of the > current popular, but slow and bloated linux apps that are turning the > Linux desktop experience into something that a Windows user would > recognise. Things like KDE, OpenOffice.org, and every browser I have > tried are very slow and bloated. Even Opera, which advertises itself as > small and quick, isn't. Quite frankly, there is no excuse for that. > Blender, a fully featured 3D editing suite, which includes almost > everything you need to do 3D work, including a game, video editor, and > animation sub systems, also includes a plugin system with lots of > plugins. It was used on such films as Scooby Doo. With all that stuff > in it, and even running in OpenGL mode, it still starts up instantly. > > As stated above, booting SuSE on an Athlon 3000+ with lots of RAM and > fast hard drives takes three minutes. Although this does include > starting up many services, the boot time with minimal services is still > way to slow for such a fast machine. My Linux takes seventeen seconds > to boot on a test box that is one tenth the power of my Athlon. While > there are only minimal services included with My Linux at the moment, > they are not included in the boot time, as they are started in parallel > on a different VT, the user is free to log on while they start up. This > means that when combined with e17, the user can be logged on and doing > useful things in about 20 seconds from your boot loader, long before > SuSE has even started loading services. Combined with Linux BIOS, this > can turn fast machines into instant start appliances. (My BIOS takes > thirty seconds to hand control to the boot loader, Linux BIOS does the > job in a second or two.) 17 seconds! you can do better than that! i challeng you to get it to below 10! i am actually quite sure it can be done. i've had a machine boot lilo ->X running glxgears in 1.6 seconds. (yes linux) there are well - come hacks invovled, but you could manage 10 to a graphical login i would say. :) but but! congrats on CARING and WORKIng at it. it seems this is not somehting major distros care much about and i agree is a pain. slow boots. bloat. everything. agreed 100%. > I like e17 and entrance, they fit the bill, and they will be made the > official display and window manager for My Linux. > > My suggested fix to slow e17 startup with lots of eaps is the same trick > I use to start up My Linux quickly independently of the services it > starts. Don't load the eaps before giving control to the user, in > fact you can load zero eaps before giving control to the user. Once > the user has control, you obviously need to load the startup eaps, but > this is already done, as the startups are invoked at that point anyway. > The rest can be either loaded on demand, or loaded in the background > afterwards. Actually both are a good strategy, load slowly in the > background, but load on demand for any that are not currently loaded. > > Only the eaps needed for modules like ibar and engage, plus the eaps for > startup programs need to be loaded first. Eaps for the favourites first > layer menu only need to be loaded mhen the user first displays that > menu, etc. In fact, there seems to be little point in loading eaps that > are never used, something the e17 seems to do now. > > Or it could just be that eap loading is currently inefficient. I > actually doubt that, since the reason you went with a binary structure > in the first place was to increase the efficiency at load time. i am so glad you brought this up. this now enters one of my favorite domains: OPTIMISING! i love optimising things :) and well - i didnt realise a large collection of eaps would kill you. for info - how many do you have? just give me a quick count of /bin/ls ~/.e/e/applications/*.eap | wc -l anyway - i need to fix this. this is of course unacceptible that this should slow e's startup down. completely unacceptible. now unfortunately some reality - e kind of does need to load them all as these .eap's are used to match a window to get an icon for it, for engage, ibar and more. e at LEAST needs the metadata from them (name, class, title, etc. matches) so it builds its in-memory mapping for eap's. now i suspect its simply masses of disk IO that slow E down. ie its opening possible a few hundred .eap files at start and that means eet loades the header directory data (1kb or less) then need sot seek to a few places int he file and get meta data and then close and move to the next. it likely touches a LOT fo disk blocks in a seemingly random fashion - this likely puts your disk into thrash mode and thus the slowness. now we coudl just use 1 big file - but this makes maintenace of the eap colelciton a nightmare. the solution i'm thinking now is a cache - a cache file listing all metadata for all .eap's in a dir that can be updated by E itself or an external cmd-line tool. e will load the cache first (ine one big seamless load from start to end) and then in slow-burn timers scan the cache to match up real files. if real fiels have changed since the cache was made, or if files have vanished they will be remvoed from the cache and the cache re-written. files not in the cache will be added. this should improve things by light years. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
