On Fri, 23 Sep 2005 23:40:14 +0200 Gabriel Rossetti <[EMAIL PROTECTED]> babbled:
> Can't you just cache the eaps that need to be visible? I doubt that he > has hundreds of eaps in his ibar/engage. yes and no. the scheme i am working on shouldn't matter - it can cche the whole lot in a few kb of cache. :) 200 eaps make about 7kb of cache... do the math for 2000 :) > 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, well its demand loaded when rendering is needed - but thats fast and only goign to load whats visible anyway - its loading all the metadata from EVERY file that is a problem. > 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. we have a decent hash already built in in ecore and also one in evas./ evas's i know if fast as its used when rendeirng text - it hash lookups every character it renders - as it renders. if its fast enough for realtime rendering... it's fast enough for everythng else :) > 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 > -- ------------- 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
