Re: undomanger performance

[Graham Cox]

> 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 to register its own undo 
> invocation? I don’t know if that’s the actual cause of your slowdown, but it 
> seems like a design to be avoided if possible. Can you instead capture a 
> single undo invocation for all affected objects? Even if you have to bundle 
> up and collect state information for all your millions of objects, having a 
> single undo invocation would likely be more efficient than millions of undo 
> invocations each with their own state information.



+1

The Undo Manager creates an NSInvocation object for every action that it 
records. That could add up to a massive memory load for a big tree with each 
node recording an action, as well as a significant performance hit.

As Martin suggests, you probably want to disable undo altogether around the big 
tree operation, enable it again afterwards, then record ONE undo task that can 
undo the entire tree operation. Many big structure designs include a “bulk 
load” operation for this sort of purpose.

—Graham



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: undomanger performance

[Martin Wierschin]

> 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 actual cause of your slowdown, but it 
seems like a design to be avoided if possible. Can you instead capture a single 
undo invocation for all affected objects? Even if you have to bundle up and 
collect state information for all your millions of objects, having a single 
undo invocation would likely be more efficient than millions of undo 
invocations each with their own state information.

~Martin Wierschin


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: undomanger performance

[Jean-Daniel Dupas]

> 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” about it. By default, the undo manager groups all undo 
> actions registered between iterations of the run loop into a single top-level 
> group.

There is other way to group action that deferring the registration until the 
end of the event loop. That’s why I said maybe.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: undomanger performance

[Quincey Morris]

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 run loop into a single top-level 
group.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: undomanger performance

[Jean-Daniel Dupas]

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 schedule the real operation and is relatively fast, but the real 
works take much more time and is deferred until the end of the current event 
handling.

> Le 30 avr. 2016 à 21:39, Georg Seifert  a écrit :
> 
> 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, there is 
> another operation triggered by the system that takes much longer than the 
> original task and it blocks the UI. It is directly linked to the undo 
> registration, if I disable it, this does not happen. 
> 
> Running Time  Self (ms)   Symbol Name
> 26258.0ms   81.3% 0,0 _dispatch_mgr_thread  0x4ef18d
> 26258.0ms   81.3% 0,0  _dispatch_mgr_thread
> 26258.0ms   81.3% 0,0   _dispatch_mgr_invoke
> 26250.0ms   81.2% 0,0_dispatch_mgr_queue_drain
> 26248.0ms   81.2% 48,0_dispatch_queue_drain
> 26168.0ms   81.0% 1,0  _dispatch_client_callout
> 26141.0ms   80.9% 97,0  _dispatch_source_set_timer3
> 25561.0ms   79.1% 25561,0_dispatch_timers_update
> 481.0ms1.4%   8,0_dispatch_resume_slow
> 2.0ms0.0% 2,0_dispatch_queue_wakeup
> 8.0ms0.0% 0,0   free
> 6.0ms0.0% 6,0   dispatch_release
> 6.0ms0.0% 6,0   _os_object_release
> 4.0ms0.0% 4,0   dispatch_resume
> 1.0ms0.0% 1,0   nano_free_definite_size
> 1.0ms0.0% 0,0   
> 12.0ms0.0%12,0 OSAtomicEnqueue
> 9.0ms0.0% 4,0  gcd_queue_item_complete_hook
> 6.0ms0.0% 1,0  _dispatch_continuation_free_to_cache_limit
> 3.0ms0.0% 2,0  
> _dispatch_introspection_queue_item_dequeue_hook
> 1.0ms0.0% 1,0  DYLD-STUB$$free
> 1.0ms0.0% 0,0  
> 2.0ms0.0% 2,0 _dispatch_introspection_callout_return
> 7.0ms0.0% 6,0_dispatch_cache_cleanup
> 1.0ms0.0% 0,0_dispatch_timers_run
> 4162.0ms   12.8%  0,0 Main Thread  0x4ef176
> 
> Does anyone has an idea what’s going on?
> 
> Thanks
> Georg Seifert
> Xcode 7.2 on MacOS 10.10.5, 27" Retina-iMac.
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

undomanger performance

[Georg Seifert]

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, there is another 
operation triggered by the system that takes much longer than the original task 
and it blocks the UI. It is directly linked to the undo registration, if I 
disable it, this does not happen. 

Running TimeSelf (ms)   Symbol Name
26258.0ms   81.3%   0,0 _dispatch_mgr_thread  0x4ef18d
26258.0ms   81.3%   0,0  _dispatch_mgr_thread
26258.0ms   81.3%   0,0   _dispatch_mgr_invoke
26250.0ms   81.2%   0,0_dispatch_mgr_queue_drain
26248.0ms   81.2%   48,0_dispatch_queue_drain
26168.0ms   81.0%   1,0  _dispatch_client_callout
26141.0ms   80.9%   97,0  _dispatch_source_set_timer3
25561.0ms   79.1%   25561,0_dispatch_timers_update
481.0ms1.4% 8,0_dispatch_resume_slow
2.0ms0.0%   2,0_dispatch_queue_wakeup
8.0ms0.0%   0,0   free
6.0ms0.0%   6,0   dispatch_release
6.0ms0.0%   6,0   _os_object_release
4.0ms0.0%   4,0   dispatch_resume
1.0ms0.0%   1,0   nano_free_definite_size
1.0ms0.0%   0,0   
12.0ms0.0%  12,0 OSAtomicEnqueue
9.0ms0.0%   4,0  gcd_queue_item_complete_hook
6.0ms0.0%   1,0  _dispatch_continuation_free_to_cache_limit
3.0ms0.0%   2,0  
_dispatch_introspection_queue_item_dequeue_hook
1.0ms0.0%   1,0  DYLD-STUB$$free
1.0ms0.0%   0,0  
2.0ms0.0%   2,0 _dispatch_introspection_callout_return
7.0ms0.0%   6,0_dispatch_cache_cleanup
1.0ms0.0%   0,0_dispatch_timers_run
4162.0ms   12.8%0,0 Main Thread  0x4ef176

Does anyone has an idea what’s going on?

Thanks
Georg Seifert
Xcode 7.2 on MacOS 10.10.5, 27" Retina-iMac.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com