[Lazarus] debug hint timing [[Re: TButton resizing is broken in Trunk's form designer]]

[Martin]

On 08/09/2011 15:24, Graeme Geldenhuys wrote:
> But a big show-stopper for me now is the new debugging hints slowness.
> I tried to disable all the new "auto cast" features that Martin
> recently added. To no avail, they seem to stay active no matter what,
> and due to that, debugging hints over objects now take around 5-10
> seconds to display. We still have no clue as to what is causing this
> slowdown. Also, it displays such a lot of information in the hint
> window now, the hint window is to big to fit my screen. And any
> "usable" information is now obfuscated by the volumes of data output.

What exactly do you mean "stay active" ?

If I uncheck "automatic type-cast for objects", then I definetely get 
the old hint (no type cast). I also watched the gdb commands => none of 
the typecast related commands were sent.

- Are the commands still send, if you disable the option?
- Is just the slowness remaining ?

If it is just the slowness, then the issue certainly lies elsewhere.


Also from your other mails:

On 08/09/2011 12:38, Graeme Geldenhuys wrote:
> I see the following line appear instantly when I hover the mouse over
> Sender in the code... Then the delay, then the lots of text output.
>
>     <-data-evaluate-expression TfpgButton(TfpgButton(Sender))^>

On 08/09/2011 13:04, Graeme Geldenhuys wrote:
> All the command you listed, and the following 2 commands (which
> generate lots of output) execute under 1 second. So the slowdown seems
> to be somewhere else, not GDB.
>
>    p TfpgButton(TfpgButton(Sender))^
>    p (^^^char(Sender)^+3)^
>

The 2nd email referred to executing by hand in gdb. Except for the 
difference between "p" and "-data-evaluate-expression" it (the 2nd) 
would mean that gdb can execute them quickly.

But the 1st indicates, that the delay is between lazarus sending the 
command, and receiving the result. Meaning either gdb, or the 
communication channel (pipe).

You were watching the "debug output window", So maybe this is updated 
delayed.
Maybe you can recompile with the following defines:
DBG_VERBOSE
and optional DBGMI_QUEUE_DEBUG

Then start lazarus from console, gdb communications (long lines 
shortened in the middle) and some other info will be printed. the 
communications will be printed to console (immediately when received)

So this could help ensuring that it is either gdb or communication.

If it is communciations, then of course it could be how lazarus reads 
the pipes => but that code has not changed, so not likely.