[KimDaBa] About the renaming issue

[Dario Spagnolo]

Various options :

 - the start-up checksum could be enabled by default but possible to
disable it via an option. This way, people with huge albums would disable
it and only run it when they really need it.
 - My PIII 650 laptop with a very slow disk performs md5 checksums at
14,5Mb/s. If we only compute the md5 checksum on the first 10kb and the
last 10kb, this would allow me to process 10,000 images in more or less
15 seconds. We might also be able to only take the first 5kb and the last
5kb, which would allow me to process 10,000 images in 7,5 seconds.

It has to be said that the it's, generally speaking, rather unlikely that
someone will store 10,000 images on a slow and therefore small hard disk
(mine is 10Gb). So we can assume that large albums will be stored on
relatively fast hard disks, let's say at least 25Mb/s (the fastest hard
disk I can test hdparm on, which is already 2 years old, gets 38Mb/s, so
25 is a low profile situation). This would bring the best option down to 4
seconds.

Dario

Daniel Berger said:
> Dario Spagnolo wrote:
>
>>Jesper K. Pedersen said:
>>
>>
>>>One quick question from a quick read though while compiling.
>>>If I split up the index.xml file, how would you the represent it in the
>>> xml
>>>files when images has been moved in KimDaBa.
>>>
>>>Imagine I have this order in KimDaBa:
>>>misc/img1 party-42/img12 misc/img2 party42/img42
>>>
>>>currently I get the order from the order in the XML file, but if I split
>>>
>>>
>>up one file per directory, I would loose that feature.
>>
>>
>>>Regarding the idea only of having md5 sums in the db (from Darios
>>>
>>>
>>email): I tried creating md5 sums for 892 images, which took approx 30
>>secs. Are you really willing to wait 30 secs/1000 image when KimDaBa
>>starts up?
>>
>>There is some first-use loading time anyway because of the thumbnail
>>generation. But it's true that 0,03 seconds/image is a bit longish (what
>>kind of computer is that ?), but I guess we could also wrap the md5
>>function so that it only takes into account the first 10kb and the last
>>10kb, no ? I guess it would still work perfectly fine for 99,999999% of
>>situations.
>>
> Think about speed!
> I've 11'600 images in KimDaBa, and my P-III 866 Notebook is getting to
> slow to have a good feeling...
> That scan would take about 330 secs -> 5,5 mins!!! No, it would even
> take longer in cause of the slower fsb etc.
> On my Home Box (2600 MHz) KimDaBa works very fluently now, and I don't
> hope it will get slower in future.
> But I'm shure, that there are peoples with more images than me.
>
>
> _______________________________________________
> KimDaBa mailing list
> KimDaBa at klaralvdalens-datakonsult.se
> http://sulaco.hrhansen.dk/mailman/listinfo/kimdaba
>


-- 
Dario Spagnolo
http://www.zaup.org