On Sun, 14 Apr 2019 21:58:01 +0200, Jean-Luc CECCOLI wrote: >> Message du 14/04/19 19:16 >> De : "KOVÃCS István" >> A : "Darktable Users List" >> Copie à : >> Objet : Re: [darktable-user] Images order in db >> >> Hello, > >> I have to admit I have not followed this discussion closely. I'd like to >> know why you care about database IDs? In most databases, the IDs are for >> internal use only, and have no meaning in the real world (they are not tied >> to time or filename, for example - the technical term is 'surrogate key'). >> So, why are the keys important to you? Can't you sort or filter your images >> based or metadata, that has real-world meaning (e.g. time taken)? > >> Kofa > > Because I think this is the cause of other behaviours that tend to slow down > the flow.
It's possible in extreme cases that this might be true, but that would involve very minimal processing of a lot of small files. I don't know how big your images are, but if you're spending more than a few tenths of a second on processing, it's going to overwhelm any issues related to ordering on disk. And even then, you have to have some idea what the ordering on disk actually is. I've done exactly that kind of optimization, but it was partly to optimize stat'ing files (reading the inodes, which are very small) and partly to optimize reading thumbnails out of packed files (which are around 10K). This mattered on disk; not so much on SSD. Your files are probably at least 5MB or so if they're JPEGs and at least 20MB if they're RAW. Assuming that the file I/O inside Darktable is reasonable (i. e. reading entire files at once), whether they're read "in order" or not isn't going to matter. > When applying a style to many pictures, having the prog reading the files to > and fro must necessarily be slower than accessing them in a row. > Maybe not that sensitive on a modern computer with SSD, plenty of fast RAM, > high performance graphics card aso, but noticeable on an old one with basic > components. Most likely not. See above. > Even importing files must be concerned : beginning at the 125th, then back to > the 43th, then 229th, 1st, 111th, 327th, 12th, etc. must be time consumming. That simply isn't how databases (and computers, in the case of large files) work. They don't operate like someone e. g. reading down a shopping list, and forgetting something because it's not in a convenient order for how the items are placed in the supermarket . What does "125th, 43rd, 229th, 1st, 111th..." mean, in any case? > And I believe this is the reason why I have to apply development copying many > times before the whole collection is complete, for instance. If you're applying the same profile to all of the files, it won't matter. If not -- if you have to do things out of order yourself -- it might be less convenient for you, but not for the computer. > Not that bothering with 10 to 15 pictures, but now I have to rework my whole > collection. And, even with "only" 23k photos, it might save me some time, > along with some nerve crises (not sure whether the term is correct). Is this affecting how you do your work, or is it only about how you think the computer is doing its work? If you think it's how the computer is doing its work, I'm curious what you think it has to do. -- Robert Krawitz <[email protected]> *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to [email protected]
