View Single Post
Old Yesterday, 06:11 PM   #4
DNSB
Bibliophagist
DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.
 
DNSB's Avatar
 
Posts: 50,700
Karma: 178402706
Join Date: Jul 2010
Location: Vancouver
Device: Kobo Sage, Libra Colour, Lenovo M8 FHD, Paperwhite 4, Tolino epos
And how many subdirectories do you have under that first level directory? For most of my testing, building the directory tree slowed down regardless of the subdirectory nesting level since the entire tree was scanned.

As for OS search? I seldom use that with calibre since, in general, I've found using the OS to access/modify a calibre library is a bad idea. I find searching from within calibre to be more flexible and faster. YMMV.

Yes, I have used a structure with directories labelled 00-FF repeated 3 times when I stored the full path & filename in a database when I was still employed (one of my managers liked trying multiple approaches). My test build with all 16,843,008 (256/65536/16,777,216) created was extremely slow to access from the OS but fast within the application.

OTOH, My Kobo ereaders store images in a 2 level structure numbered from 000 to 255 in each level though that path is, I think, derived from a hashing algorithm and not storing names in a database.
DNSB is online now   Reply With Quote