[KimDaBa] Profiling Kimdaba startup

[Robert L Krawitz]

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

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.

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

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton