[KimDaBa] Profiling Kimdaba startup
Jesper K. Pedersen
blackie at blackie.dk
Tue Jan 4 12:52:56 GMT 2005
On Tuesday 04 January 2005 13:48, Robert L Krawitz wrote:
| From: "Jesper K. Pedersen" <blackie at blackie.dk>
| Date: Tue, 4 Jan 2005 09:06:30 +0100
| On Tuesday 04 January 2005 09:01, Eivind wrote:
| | On Tuesday 04 January 2005 07:46, Jesper K. Pedersen wrote:
| | > Robert, thx for your profiling.
| | > As it looks now, I can't see that there are any thing else I can do
| | > to speed up things, except rewritting to a real database.
| | >
| | > Rewritting to a real db would be a huge job, and currently I dont
| | > see it worth it to save at most 2.5+1=3.5 secs. People with 50.000
| | > images might disagree, but we aren't really there yet
| | I agree with this. Spending lots of time to change to a "real db"
| | isn't likely to deserve being on the top of the priority list at
| | present. Though I do think that keeping the thougth is a good idea,
| | for example in trying to not needlessly further complicate a later
| | switch.
| Sure, I've done so from the very start.
| The startup code doesn't appear to be very complicated. It would be
| interesting, as an exercise, to replace it with code using mxml (a
| light weight XML parser).
At some point I tried replacing the DOM parser with a SAX parser, and after a
long night of work I gave up. One thing is the parser, the second thing is
that you need to restructure the internals of kimdaba too.
| | > (at least that is not what I hear from most kimdaba users), and once
| | > we are there, computers are likely so much faster that the 25 secs
| | > has gone done.
| | This however, I disagree with.
| | A real db migth bring faster startup-times, which is important
| | for people with humongous collections of pictures. I think this
| | group of people is going to grow very quickly as the years with
| | digital cameras pass. I know that my picture-collection grows by
| | atleast a couple of thousand images a year, and I'm probably not
| | the only one.
| See here I kind of disagree, Even with 2000 images per year, you
| will spent 12.5 year to get to 25000 images, by the computers will
| be able to read a billion image database (in its current XML
| format) in a fraction of a second. But as I said before, lets see,
| if a huge amount of users get databases which are this size, I will
| 2000 images per year isn't very many. I'm not a professional, and yet
| I shot 5000 images this year without even trying very hard. I don't
| think computers (and storage) will get that fast for single data and
| instruction streams any time soon; the recent trend seems to be more
| toward multi-processing chips to improve system performance. However,
| I do think that if you set 50K images to be a reasonable target, then
| current machines can handle it without great difficulty.
Lets just agree that for the time being we will just monitor the situation,
and once a lot of kimdaba users complain, I'll have another look. In the
meantime I'll waste my sparetime on other cool topics like the datebar
| | Secondly, startup-time ain't the only reason a real database can
| | be desireable. Another reason that in certain setting is atleast
| | as important is multiuser-functionality. With a real database it
| | should be possible for more than one person to work against a
| | single image-archive. This is a showstopper for basically any
| | professional or half-professional use where the users are more
| | than a single person at a time. Similarily it should allow more
| | fine-grained access-control since typical databases come with
| | such built-in.
| I agree with the multi user issue, but on that issue my point is
| very clear - I'm not going to spent a single minute of my spare
| time on developing features in kimdaba that only professionals gain
| something from. If a picture company (or whatever such places are
| called) are going to save a lot of time from kimdaba, they should
| find their wallet fast, and I'll tell them my account number ;-)
| Seriously, I hope that such people will see the quality in KimDaBa,
| and start sponsoring features that are of special interest to them.
| That's fair. Multi-user functionality is very specialized. It's not
| clear to me how useful this would even be to most professionals
| running a studio with just a few employees. It would be much more
| useful to much larger operations like National Geographic, with lots
| of photographers and editors, and there aren't a lot of those and they
| can afford to spend more on it.
| Making Kimdaba multi-user would require a lot more than simply a
| database back end.
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 Kphotoalbum