Carsten Haitzler (The Rasterman) wrote:
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 :)
Ok,cool :-) cache rocks!
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 :)
Yes, that's fast then :-)
Great work on e17 by the way!
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
-------------------------------------------------------
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
|
