[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: TMS structure changes (was Re: ANNOUNCE: Thumbnail Managing Standard 0.6)



On Tue, Sep 03, 2002 at 08:12:08AM +0200, Jens Finke wrote:
> Hello,
> 
> On 2 Sep 2002, Sven Neumann wrote:
> > > Still haven't had any reports of problems with the current
> > > system. Just curious, but what system was the user running who found
> > > it didn't work for them?
> >
> > as far as I know noone reported any problems. The problems we
> > discussed here have been of purely theoretical nature.
> 
> Consider a user has multiple hundreds if not thousands of image files
> (which is quite possible if you do a lot of digitial photographing). The
> thumbnails for all these files will just go into a single directory. I
> think too, that this won't cause problems with e.g 500 files. But the
> question is how scalable this structure is, which of course is also a
> matter of the underlying filesystem. Maybe there are fs which have a
> maximum number of files per directory. Hitting this limit would be very
> bad.
> The situation could be worse, if people start to store thumbnails also
> for other filetypes, like PDF files.

Right, but your change doesn't fix this. You are worried that a system
will fail or become unacceptably slow with 'n' files. You claim this isn't
scaleable on old systems. Maybe. You're now proposing we replace this with
a system which will fail or become unacceptably slow with 'n * 16' files.

ie, you're suggesting we break an unscalable O(n) system in order to
replace it with an equally unscalable O(n) system.

OTOH, if the user upgrades their kernel/fs then they get O(1), which
fixes any problems cleanly (even linux 2.2.x does this, if I'm reading it
right; d_lookup() gets the dentry from a hash of the basename).

So:

- It doesn't seem to be a problem (we have users with many thousands of
  photos).

- It shouldn't be a problem (kernel will use a hash table for constant
  time lookups once the directory is in the cache, and with only 16
  buckets everything would get loaded into the cache anyway).

- Even if it was a problem, the above change wouldn't fix it. It would
  only slightly delay it, like x86 going from 64K memory limit to 640K.

- Even if the name was being looked up in a linked list and the user has
  hundereds of thousands of photos, it still seems likely that the lookup
  time would be dwarfed by the image loading time.

Unless I'm missing something obvious?


-- 
Thomas Leonard			http://rox.sourceforge.net
tal00r ecs soton ac uk		tal197 users sourceforge net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]