Great work, Denis! We have to look at how the GTDebugger works with large stacks. Could you please open an issue for that?
Cheers, Doru > On Sep 19, 2016, at 10:36 AM, Denis Kudriashov <[email protected]> wrote: > > 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 <[email protected]>: > >> On 16 Aug 2016, at 10:11, Denis Kudriashov <[email protected]> wrote: >> >> >> 2016-08-14 10:19 GMT+02:00 Sven Van Caekenberghe <[email protected]>: >> 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... > > -- www.tudorgirba.com www.feenk.com "If you can't say why something is relevant, it probably isn't."
