A bug was recently reported for Notepad++ where an operation that worked reasonably without change history used excessive memory with change history.
The problem example deletes around 150,000 lines individually (one line at a time) in reverse direction - from the end of the file to the beginning. These particular circumstances are required: contiguous deletions in a backwards direction. Its fine if the loop is changed to iterate forwards from the start of file, or the deletions are merged into large blocks. Holding the backspace key down for an hour would also become slow.
When text is deleted, earlier deletions within that text are shown at the deletion position but their previous positions are remembered so they can be restored if that deletion is undone. Deletions that were already at the deletion position don't need to be remembered as they didn't move. This is the difference between forwards and backwards deletions with backwards deletions building up large lists.
The large lists contain many repeated elements looking like
[
Deletion(position:100,edition:unsaved),
Deletion(position:100,edition:unsaved),
...
]
Adding a 'count' field allows compressing these down sgnificantly:
[ Deletion(position:100,edition:unsaved,count:23) ]
The compression technique fixes the memory use and thus speed of the problem example but increases memory use for sparser or more random scenarios. It appears to be an OK trade-off to me. It also depends on the limited number of editions currently tracked (original, unsaved, saved, reverted, revertedToChanged) and would not work if edition meant modification number in session as it did in an early design. Tracking
modification numbers could allow additional features like showing how old each change is.
Attached is a patch that implements this.
Neil