update album date according to its contents
Bug 422078 (https://bugs.kde.org/show_bug.cgi?id=422078)
This is a time optimized solution. I did some comparison, see the table below:
Folder name | No new album before PR | No new album with PR | New album before PR | New album with PR |
---|---|---|---|---|
2006 | 3593 | 4135 | 3411 | 3571 |
2007 | 4514 | 4265 | 4468 | 5504 |
2008 | 4507 | 4844 | 4293 | 3691 |
2009 | 24944 | 24111 | 22605 | 30402 |
2010 | 6676 | 5883 | 8318 | 3564 |
2011 | 22628 | 15218 | 15974 | 13652 |
2012 | 20749 | 16841 | 19750 | 13830 |
2013 | 30357 | 25645 | 28606 | 19873 |
2014 | 28049 | 21081 | 27152 | 19801 |
2015 | 21889 | 18154 | 20549 | 17887 |
2016 | 5249 | 3435 | 3839 | 4368 |
2017 | 97313 | 113851 | 82939 | 86102 |
2017_copy | 38505471 | 41954948 | ||
2018 | 4394 | 4235 | 8017 | 4154 |
2019 | 48500 | 37364 | 50719 | 53110 |
2020 | 6874 | 6803 | 6234 | 5976 |
/older | 4929 | 4275 | 5071 | 4215 |
/ | 344897 | 318724 | 38833985 | 42258422 |
All values are already an average of 3 measurements in the unit us for each run of the function CollectionScanner::scanAlbum(). This is the only place this patch has en effect on. For me the most significant part is in case of creating a new album. This slows down the scanning of the new album by around 8%.
The album 2017 contained 1788 pictures.
Edited by Marcel Mathis