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 <dionisi...@gmail.com> 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 <maxle...@gmail.com>:
> 
>> On 16 Aug 2016, at 10:11, Denis Kudriashov <dionisi...@gmail.com> wrote:
>> 
>> 
>> 2016-08-14 10:19 GMT+02:00 Sven Van Caekenberghe <s...@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...
> 
> 

--
www.tudorgirba.com
www.feenk.com

"If you can't say why something is relevant, 
it probably isn't."


Reply via email to