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 <georg.seif...@gmx.de> 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.0ms 1.4% 8,0 _dispatch_resume_slow > 2.0ms 0.0% 2,0 _dispatch_queue_wakeup > 8.0ms 0.0% 0,0 free > 6.0ms 0.0% 6,0 dispatch_release > 6.0ms 0.0% 6,0 _os_object_release > 4.0ms 0.0% 4,0 dispatch_resume > 1.0ms 0.0% 1,0 nano_free_definite_size > 1.0ms 0.0% 0,0 <Unknown Address> > 12.0ms 0.0% 12,0 OSAtomicEnqueue > 9.0ms 0.0% 4,0 gcd_queue_item_complete_hook > 6.0ms 0.0% 1,0 _dispatch_continuation_free_to_cache_limit > 3.0ms 0.0% 2,0 > _dispatch_introspection_queue_item_dequeue_hook > 1.0ms 0.0% 1,0 DYLD-STUB$$free > 1.0ms 0.0% 0,0 <Unknown Address> > 2.0ms 0.0% 2,0 _dispatch_introspection_callout_return > 7.0ms 0.0% 6,0 _dispatch_cache_cleanup > 1.0ms 0.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
