Package: krita Version: 1:5.3.4+dfsg-1 Severity: normal Tags: upstream Dear Maintainer,
With a fresh profile, Krita's first start writes its resource cache with one disk sync per SQL statement. On a 7200 rpm hard disk that keeps it on the splash screen for minutes, and it is easy to take it for a hang. Measured with strace, counting fdatasync calls on a fresh profile: - Krita 1:5.3.4+dfsg-1: 6787 - Krita 6.0.4 (built from Debian's 1:6.0.4+dfsg-1 packaging): 6908 Cause: KisResourceCacheDb::updateMetaDataForId() (libs/resources) starts and commits a transaction of its own. When it is called from addResources(), which already has one open, its BEGIN fails and its COMMIT ends the caller's transaction. Every later statement then commits on its own, each with its own sync. addMetaDataForId() can also roll back a transaction it did not start. The same code is in upstream master. When the function commits or rolls back only a transaction it started itself, the count drops to 504, with the same database contents (901 resources, 11 tags), and the first start finishes even with 15 ms per sync. We are not sending a patch upstream, out of respect for Krita's AI moratorium (in Krita's README); this report is so a developer can make the change, and please forward it upstream as you see fit. This report was written with AI assistance; I directed and verified the measurements. Daniel Ramos
