https://bugs.kde.org/show_bug.cgi?id=396086
--- Comment #37 from caulier.gil...@gmail.com --- The scan process in DK is divided in 2 parts which are bottlenecks: 1/ scan of albums in recursive mode without contents inside. This populate few database tables. 2/ scan album contents listed in DB. This include all files registered in mimetype to support (photo and video). Other tables in database are populated. Depending of collection sizes, both can take a while, but 2/ is always the most important. 1/ can be certainly parallelized, but in fact all is serialized in database. Even if we use multicore here to list directory, the gain will be minor. 2/ can be parallelized. The most import component used to populated the database with items properties is Exiv2 for photo, and ffmpeg for video. Even if Exiv2 support multicore, Exiv2 use memory and is not optimum. If an improvement must be done it's here. So it's an UPSTREAM problem, already reported to Exiv2 team, but i never seen an improvements in this area. In all cases, if we parallelize metadata parsing, the database serialization will limit the gain, excepted if the registration of items in database is done by chuncks of items, and not one by one. And even if we chunck registration of items, i'm not sure if the gain will be visible with SQlite. Certainly it will be better with Mysql/Mariadb, especially with a remote server. Voilà for few explainations of DK DB scannner. To resume, as Maik said, the one image linked plenty of time is not a valid test. The only parts which can be tested like this is 1/ Gilles Caulier -- You are receiving this mail because: You are watching all bug changes.
