So I opened this case��19108��and submitted slice which restricts logging time to 100 milliseconds. (it should be enough, look at issue explanation).

��

But also there is some problem with GTDebugger which talk with full stack items instead of visible ones. It slowdown opening on big stack (which is usual for recursion cases).��

To see problem just open in browser Context>>sender and put counter on sender variable (from suggestion menu). Also disable stack logging by "DebugSession logDebuggerStackToFile: false".

Now execute "1 recursionTest" from workspace and after 3 seconds press cmd+.. You will see 11610 calls of "context sender". Interesting that with SpecDebugger it is just 42 calls.

2016-08-16 11:30 GMT+02:00 Max Leske <maxleske@gmail.com>:

On 16 Aug 2016, at 10:11, Denis Kudriashov <dionisiydk@gmail.com> wrote:

2016-08-14 10:19 GMT+02:00 Sven Van Caekenberghe <sven@stfx.eu>:
But the slowness comes from printing a too large stack, no ?
Why not just limit the size of the stack being printed ?

Maybe it is better to limit time which could be spend on log writing. Sometime I guess writing to log itself raises errors and recursions which could be another reason for non working cmd+..
We could limit it for 1 second. And if it is not enough then append extra ~20 contexts from root which will show reason for possible recursion (also limited in time). What you think?

That sounds like too much magic to me...