I recall once having the mentioned “exponential list growth” (undo) problem using a certain framework. It is very natural for a framework to record changes, one by one, as they happen, but it is also generally recognized that such exponential undo-lists can choke the system if many items in the list are modified in a for-loop for example.
The typical solution is then usually to provide a manual “transaction” which the user can strat before starting to modify the list, and then “commit” after the list is done modified. And between the “StartTransaction” and “CommitTransaction” the system simply skips recording the individual modifications and instead records only the total “batch” and saves that single record on CommitTransation.
It may well be that the McNeel developers has foreseen this phenomenon, and provided a means to handle just that (but McNeel would have to confirm that because I don’t have time to test it right now), but have a look at this command (BeginUndoRecord) and it’s complementary command (EndUndoRecord). To me it looks suspiciously like a similar concept as the above mentioned StartTranscation 6 CommitTransaction:
Perhaps this will resolve the performance problem by simply recording one (1) undo-action, doing away with the “exponential” undo-problem. Who knows…