Re: -stack-list-locals and children

[Vladimir Prus <vladimir@codesourcery.com>]

Niko Sams wrote:

> On Mon, Jun 29, 2009 at 10:17, Vladimir Prus<vladimir@codesourcery.com> wrote:
>> [I assume you did not CC list accidentally, readding it back]
>>
>> On Monday 29 June 2009 you wrote:
>>
>>> >> Basic tests showed me that -var-create is relatively slow for large lists.
>>> >
>>> > How slow and how did you measure this? I would not expect variable objects to
>>> > be considerably slower than printing the value in any other way.
>>> I measured using -enable-timings. I did -var-create for a QStringList
>>> with 1000 items,
>>> took 0.6sec.
>>
>> This is the current problem with GDB -- it will always try to fetch all
>> children, which has other problems besides performance. In particular,
>> if you try to get children of an invalid object, gdb might never finish.
>> Tom is planning to address this issue soon, and we'll be able to have
>> incremental fetch of varobj children -- much like we have for stack
>> frames in KDevelop already.
> ok, I see.
> When this is fixed -var-create should be faster?

I'd imagine there be global changeable default number of children to fetch,
say 10, so yes, it will be faster.

>> Also, is -stack-list-locals any better here? I'd expect it to either have
>> exactly the same performance problems, or ignore pretty-printing. If it
>> is considerably faster while still reporting 1000 children, it's performance
>> bug somewhere.
> It's much faster. I get about 100 children in the value followed by ....

Ah, hmm. Seems like CLI obeys 'set print elements' setting, then. When MI
obeys it's own limit, I expect there to be no difference.

- Volodya