[KPhotoAlbum] extragear/graphics/kphotoalbum

[Jesper K. Pedersen]

On Tuesday 22 May 2007, Shawn Willden wrote:
| On Tuesday 22 May 2007 05:55:19 am Jesper K. Pedersen wrote:
| > If there is a problem with the implementation, then I think time is
| > better spent trying to figure out what takes time, rather than spenting
| > the time in the future fixing a bug which comes from this setting.
|
| In this case, the linear scan is done to find the single selected image's
| position in the list of all images.
|
| If the database happens to be sorted in chronological order (and I know
| that's checked on startup) might it be possible to locate the image with a
| binary search by date?  Looking at the data structures, I think it could. 
| Each date comparison would require a lookup of the image info by filename,
| but that's implemented with a map, so it's fairly fast.  Seeking around in
| the list of file names is linear, because a QStringList is a linked list,
| but that's not too bad.
|
| If currentContext() were to return, say, a std::vector<QString> rather than
| a QStringList, the binary search would not only be fast, but you could use
| STL-provided search algorithms to do it.  In general, I wonder if it
| wouldn't make sense to use vectors in many places where lists are currently
| used. This is just idle thought, though, I'm certainly not volunteering to
| "fix" that, even assuming it could benefit from the change.
|
| 	Shawn.

I seriously dont thing that running though a list of say 20.000 strings and 
comparing cost much, I'm way more concerned about stat'ing. But in any case 
this is something that should be profiled before "fixed". Our first and 
foremost task should always be readability of code.

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

http://www.kphotoalbum.org might be the answer.