From f4da329a1afa4808cbd47182a86cc2b19bcaa984 Mon Sep 17 00:00:00 2001 From: Robin Haberkorn Date: Tue, 7 Mar 2017 23:53:03 +0100 Subject: undo stack reorganized into a stack of undo token lists * in a flat list of undo tokens, we need to store the program counter (ie. command line position) that the undo token corresponds to. Since in general there is more than one undo token per input character, this stored PCs redundantly. * For input characters with no undo tokens (only applies to NOPs like space in the command line macro), this needs one more pointer than before. * In case of 1 undo token per input character, the new implementation uses approx. the same memory. * In the most common case of more than one undo token per input character, this saves at least 4 bytes per undo token. * In large macros and long loops the effect is especially pronounced. E.g. 500000<%A> will use 8MB less memory with the new implementation. --- TODO | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) (limited to 'TODO') diff --git a/TODO b/TODO index 9748f6f..4f93a5e 100644 --- a/TODO +++ b/TODO @@ -84,6 +84,8 @@ Known Bugs: Also, auto-completions within string-building constructs (except Q-Reg specs) should generally be disabled since the result will be unpredictable. + * Shutdown seems to hang after generating lots of undo tokens: + 500000<%A>EX$$ Features: * Auto-indention could be implemented via context-sensitive @@ -289,9 +291,6 @@ Optimizations: * RTTI could be disabled (-fno-rtti). It's only still required because of StdError() for handling arbitrary C++ exceptions. This is probably not required. - * The position can be eliminated from UndoTokens by - rewriting the UndoStack into a stack of UndoToken lists. - Should be a significant memory reduction in interactive mode. * RBTrees define an entry field for storing node color. This can be avoided on most platforms where G_MEM_ALIGN > 1 by encoding the color in the -- cgit v1.2.3