[KimDaBa] Profiling Kimdaba startup

[Robert L Krawitz]

   From: "Jesper K. Pedersen" <blackie at blackie.dk>
   Date: Wed, 5 Jan 2005 18:58:55 +0100

   When I teach Qt courses I always teach people to make simple things
   simple, and never optimize without having done proper profilation
   first.

Otherwise known as "premature optimization is the root of all evil".
That approach is absolutely correct.  With that kind of philosophy, it
doesn't surprise me that Kimdaba is so fast.

   And for the files. Maybe things would parse a bit faster, but
   editing the files by hand in case kimdaba did something bad, might
   very likely be much harder.

I agree with this, too.  Especially since I've periodically had to fix
it by hand.

   I'm pretty proud about how bug free kimdaba really is - sure it has
   its bugs, but nothing real bad. I believe this is because I strive
   towards very easy to read code, and avoiding to hash strings is one
   of the things that keeps is simple.

Often times the best way to get good performance is simply to run very
little code, so keeping it small and simple also makes it fast.  The
1-5% that really matters is what you tune if need be.

This all said, I did run a quick benchmark of using mxml to parse the
index.xml file, and it is considerably faster than the Qt equivalent
-- it took about .8 seconds, vs. 2.5 with the Qt DOM parser (my
index.xml is now slightly bigger than it was when I tested it with the
Qt parser, but the difference is not significant).  The other 1.5
seconds or so spent building the internal database would probably not
be affected to any great degree (just a guess -- I haven't tried it),
in which case it would save about 40% of the variable part of the
startup time.  So this is an optimization that might be considered in
the future if you think it would be worthwhile to improve startup
time.  Mxml is a very light weight XML library that we simply compile
into Gimp-Print.  It's written in very plain ANSI C.

Another thing I noticed -- I tried gwenview, which is also quite
fast.  It doesn't actually build the thumbnails quite as fast as
Kimdaba, but it scrolls through them much faster (it doesn't seem to
have to keep reloading them from disk).  It doesn't appear to be a
memory pig either, so it might be worthwhile figuring out what they
do.  Scrolling through thumbnails is somewhat slow in the current
snapshot, and it might be worthwhile to speed that up some.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton