Can't you just cache the eaps that need to be visible? I doubt that he has hundreds of eaps in his ibar/engage. It would speed things up if the visible eaps are stored in a big file (ie when you add them to ibar or engage or a menu) and load the others if they are needed later on? 10 times out of 9 we use programs that are in our menu/ibar/engage first, that's why we put them there in the first place. For later loads, we could store the eap in a hash table with the window class as a key, so when the program loads, we read the window class and get the info for it. My last idea si if you don't want to load the rest of the eaps later on, as this is a "windows-like" solution :-( and we all hate having our gui up and not being able to use it for two mins. Of course, I have no idea on how you use the eaps in association with windows, but from what I understand you need to have them in memory when you load a window. I say that google gpl'd some apperently fast hash implementations on sourceforge.
Carsten Haitzler (The Rasterman) wrote: >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. :) > > > ------------------------------------------------------- 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
