https://bugs.kde.org/show_bug.cgi?id=356357
--- Comment #15 from tagwer...@innerjoin.org ---
Is this still an issue ... ?
... To the extent that it can be pinned down to syncing writes
to the index?
I think there are still things to look at - for example batching up the initial
indexing when there are *very* *many* new files to index (Bug 394750),
adjusting the number of files "indexed in a batch" when content indexing (Bug
373021), and dealing with many deleted items (possibly Bug 437754 or Bug
353874. I'm not sure there's a bug specifically that clearing up deleted items
is slow)
I think these are more related making sure you commit before you "risk" using
swap but also you make maximum use of RAM so you don't commit too often.
I don't think the attached patch
https://bugs.kde.org/attachment.cgi?id=95923
that avoids the "sync" after each transaction was applied. This was also
proposed (2019/09) here:
https://bugs.kde.org/show_bug.cgi?id=404057#c12
It may be that "batching up" the indexing, implying fewer, larger,
transactions, reduced the advantage
For Bug 400704, most of the reports date from 2017/2018.
I am tempted to flag this as "needs info" to see if there are other test cases
that need to be looked at...
--
You are receiving this mail because:
You are watching all bug changes.
