Re: undomanger performance

> On 3 May 2016, at 6:10 AM, Martin Wierschin wrote: > >> My app deals with an object tree that can have millions of leaves. It is >> possible to run an operation on all of them. Each will register its own >> change with the undo manager. > > Is it absolutely necessary for each leaf object t

Re: undomanger performance

> My app deals with an object tree that can have millions of leaves. It is > possible to run an operation on all of them. Each will register its own > change with the undo manager. Is it absolutely necessary for each leaf object to register its own undo invocation? I don’t know if that’s the a

Re: undomanger performance

> Le 1 mai 2016 à 01:42, Quincey Morris a > écrit : > > On Apr 30, 2016, at 12:49 , Jean-Daniel Dupas > wrote: >> >> Maybe registering the changes is not executed immediately but deferred until >> the end of the current event loop cycle > > There’s no “maybe” ab

Re: undomanger performance

On Apr 30, 2016, at 12:49 , Jean-Daniel Dupas wrote: > > Maybe registering the changes is not executed immediately but deferred until > the end of the current event loop cycle There’s no “maybe” about it. By default, the undo manager groups all undo actions registered between iterations of the

Re: undomanger performance

Just my 2 cents. Maybe registering the changes is not executed immediately but deferred until the end of the current event loop cycle, so the undo manager can group them into a single operation. In such case, it would mean that what you think is the undo registration is just a call to schedul

undomanger performance

Hi My app deals with an object tree that can have millions of leaves. It is possible to run an operation on all of them. Each will register its own change with the undo manager. The hole operation might tale a few second (the last line in the trace below). But after my operation is finished, th