Most of the time was spent allocating space for the hashdata.
The perf numbers speak by themself:
from 42.3% (cycles inc.)
to 16.1% (cycles inc.)
Details
Details
- Reviewers
- None
- Group Reviewers
Kate Frameworks
to 16.1% (cycles inc.)
repeat {
Paste, go to beginning of file
} 5 times
Undo 5 times
Diff Detail
Diff Detail
- Repository
- R39 KTextEditor
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Comment Actions
@mwolff To me this looks ok - do you see an issue with this? E.g. that KTextEditor will require much more memory for almost no gain?
Comment Actions
I wonder if that really makes sense, given not all blocks contain ranges at all and they not really correlate with the block size.
Does that change really make it much faster or just shift the costs?
Comment Actions
If there is a more constrained limit, this should be changed, of course.
I wonder if that really makes sense, given not all blocks contain ranges at all and they not really correlate with the block size.
Does that change really make it much faster or just shift the costs?
In my tests it doen't really make it much faster, but now the top cost in undo is really the undo method, not QHash memory management.
Comment Actions
More numbers:
The patch reserves 67 buckets in the QHash table vs. 37 by default.
In my test, pasing the content of https://www.boe.es/legislacion/documentos/ConstitucionCASTELLANO.pdf from Okular,
the number of items in the cache is a maximum of 24 members when inserting.
But the first undo uses up to 2300 members (4099 buckets), and later undoes only use a maximum of 43 members.
The performance problem is in the first undo. What could be the difference between the first undo and subsequent undoes?