[KimDaBa] Profiling Kimdaba startup

Jesper K. Pedersen blackie at blackie.dk
Wed Jan 5 18:58:55 CET 2005

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

A long time ago, I was having the trouble that kimdaba was to slow during 
browsing, and I thought to myself, "hmm that gotta be because I keep 
everything as string, and does a lot of string comparisons during browsing".
Fortunately I remembered what I teach, and profiled things, and it turned out 
that making one single QStringList static, and emptying it over and over 
again costed 80% of the time - string comparison didn't even show up in top 
10 of time wasted.

So changing things to hash keys would gain me no speed whatsoever. I might 
save a few bytes of memory, but I doubt that anyone here would even notice.

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 

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 

Hope that clarifies things.
On Wednesday 05 January 2005 16:40, Jody Harris wrote:
| Robert L Krawitz wrote:
| <snip>
| > To demonstrate this, I did the following test (it's necessary to use
| > two cat processes in a pipeline, because the way cat works, using
| > memory mapped I/O, if the destination is /dev/null it does almost no
| > work).  Note that the second time (when the file was in memory) the
| > amount of time spent was completely negligible.
| <snip>
| Okay, thanks for clearing that up for me.  I knew it wasn't that simple.
|   I just wasn't adding things up.  May I claim the, "It was late," excuse?
| There are still some advantages to storing compressed data...
| which brings me to a question I've never asked (which may or may not
| relate to speed):
| In index.xml, I have a list of "Keywords" in values (the same for
| Locations, Persons, and any top-level categories I create).  When I get
| down to the image data, every "value" is repeated in full text.
| I would have approached it differently.  I would have created an index,
| and assigned values to those indexes.  Then, rather than repeating the
| verbose value in the image record, I would just have given a list of
| indexes.
| Yours:
|    <option viewtype="0" viewsize="0" icon="password" name="Keywords"
| show="1" >
|     <value value="Christmas" />
|     <value value="music" />
|     <value value="Church" />
|     <value value="Barn" />
|     <value value="rainbow" />
|     ...
| Mine:
|    <option viewtype="0" viewsize="0" icon="password" name="Keywords"
| show="1" >
|     <value index=1 value="Christmas" />
|     <value index=2 value="music" />
|     <value index=3 value="Church" />
|     <value index=4 value="Barn" />
|     <value index=5 value="rainbow" />
|     ...
| In memory, I would have created a hash for each category, then used that
| hash to populate any output functions.  (Warning: I think in Perl.)
| Building the hash reference by hand would have looked like this:
| $keywordref = {
| 	1 => "Christmas",
| 	2 => "music",
| 	3 => "Church",
| 	4 => "rainbow",
| 	...
| 	}
| Output would look something like:
| 	print "Persons: "
| 	foreach (@image_persons)
| 	{
| 		print "$keywordref->{$_}, ";
| 	}
| where @image_persons is a per-image array of keyword indexes.  (Add all
| the wrap for sorting, presentation, etc.)
| It seems to me, and again, I could be completely off track, that parsing:
| 	<option name="Keywords" >
| 		<value value="1, 2, 3, 4" >
| 	</option>
| would be quicker.
| I'm sure there's a reason you did it the way you did it.  Could you
| illuminate?
| Thanks,
| jody

Having trouble finding a given image in your collection containing
thousands of images?

http://ktown.kde.org/kimdaba might be the answer.

More information about the KimDaBa mailing list