[KimDaBa] Profiling Kimdaba startup

[Jesper K. Pedersen]

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 
harder.

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.

Hope that clarifies things.
 
Cheers
Jesper.
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.