https://bugs.kde.org/show_bug.cgi?id=475205
--- Comment #1 from Benoît Tarrade <benoittarr...@hotmail.fr> --- After some digging, I can tell a few things : * Calculating hashes at every project load for every element (more exactly documentProducers and documentChains) takes up some time. * Updating the timeline with Mlt takes up a huge amount of time as well (I'm trying to profile that, but I think I will end up using stopwatches because profiling is far too heavy). I haven't gotten to the point of loading thumbnails and populating the resource explorer yet, but there is a big target before this. For the hashes, I think we can safely try to : * Compare the modification timestamp * If timestamp differs, then we might compute the hash of the file * alternatively, we can try to compute a hash for the N last bytes of a file (we'll be very lucky if 2 different files have the same tail hash!), which is much less expensive because the dataset size is much shorter, it might be quite faster I understand that this is an addition to the XML tags in the kdenlive doc, but as this probably is a new item (?) it shouldn't break serialization. I believe we can also split the list of candidates to be checked (lines 182 to 193 of documentchecker.cpp, with the linear for loop) and try to break it down and give it to eat to worker threads. I suppose there's no resource racing condition with the hashing function (but I might be wrong, in such a case it won't be much of a help to parallelize this execution). Furthermore, later in the projectmanager.cpp, after all the hashing calculations and a bunch of stuff, we try to update the timeline using the projectManager::updateTimeline(...) function. Instantiation of the Mlt::Producer (std::unique_ptr) takes a lot of time as well. I'll try to investigate that a bit. -- You are receiving this mail because: You are watching all bug changes.
