Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Raphael Zulliger <zulliger@indel.ch>
To: "gdb@sourceware.org" <gdb@sourceware.org>
Subject: Performance issue of -var-list-children on structs with many members and remote targets
Date: Fri, 08 Aug 2014 07:25:00 -0000	[thread overview]
Message-ID: <53E47B59.3060700@indel.ch> (raw)

This mail is about a proposal for improving GDB/GDBServer speed for 
-var-list-children on large structs.

I have the following performance issue: Using Eclipse/CDT, expanding a 
large structs (roughly 1000 members) on an embedded target (target 
extended-remote) to inspect the members of a struct takes about 15 
seconds on a not that out-dated Windows PC.

According to my investigation, the major amount of this time is spent 
exchanging data between GDB and our own GDBServer implementation (which 
btw. also runs on the same PC, not on the embedded system). Assume we 
have the following code:

struct S {
     double a, b, c;
} g_s;

int main() {
     return 0;
}

When expanding g_s in Eclipse/Luna the following happens with gdb/master 
(Aug 4 2014) on Ubuntu 14.04/64:

499,882 37-var-list-children var2
499,882 
37^done,numchild="1",children=[child={name="var2.public",exp="public",numchild="3"}],has_mor\
e="0"
499,882 (gdb)
499,883 38-var-list-children var2.public
499,884 &"Sending packet: $m601050,8#fd..."
499,884 &"Packet received: 0000000000000000\n"
499,884 &"Sending packet: $m601058,8#05..."
499,884 &"Packet received: 0000000000000000\n"
499,884 &"Sending packet: $m601060,8#fe..."
499,884 &"Packet received: 0000000000000000\n"
499,884 
38^done,numchild="3",children=[child={name="var2.public.a",exp="a",numchild="0",type="double\
"},child={name="var2.public.b",exp="b",numchild="0",type="double"},child={name="var2.public.c",exp="\
c",numchild="0",type="double"}],has_more="0"
499,884 (gdb)
499,885 39-var-info-path-expression var2.public.a
499,885 40-var-info-path-expression var2.public.b
499,885 41-var-info-path-expression var2.public.c
499,885 39^done,path_expr="((g_s).a)"
499,885 (gdb)
499,886 40^done,path_expr="((g_s).b)"
499,886 (gdb)
499,886 41^done,path_expr="((g_s).c)"
499,886 (gdb)
499,892 42-var-evaluate-expression var2.public.a
499,893 42^done,value="0"
499,893 (gdb)

Projecting these traces back to my large-scale example with about 1000 
members in 'struct S', it's the following part that consumes the major 
amount of time (measured using "Process monitor"'s activity feature 
which clearly shows high network traffic and CPU consumption of both, 
GDB and our GDBServer processes during roughly 10 seconds):

499,883 38-var-list-children var2.public
499,884 &"Sending packet: $m601050,8#fd..."
499,884 &"Packet received: 0000000000000000\n"
499,884 &"Sending packet: $m601058,8#05..."
499,884 &"Packet received: 0000000000000000\n"
499,884 &"Sending packet: $m601060,8#fe..."
499,884 &"Packet received: 0000000000000000\n"

Now my simple question: Couldn't GDB be tweaked to get the struct member 
values by just one call (because members within a struct are guaranteed 
to be consecutive, aren't they?):

499,883 38-var-list-children var2.public
499,884 &"Sending packet: $m601050,24#??"

I guess this would dramatically increase overall performance.

I would really like to see such an improvement in GDB. Therefore, I'd be 
very happy to hear your thoughts and suggestion. Thinks like: What 
problems (e.g. border cases) could arise when implementing this? Where 
to start in the GDB code for such a modification? Or do there exist any 
GDB switches to improve performance on such operations? etc...

Thanks a lot!
Raphael


             reply	other threads:[~2014-08-08  7:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-08  7:25 Raphael Zulliger [this message]
2014-08-08 10:35 ` Yao Qi
2014-08-11 14:57   ` Raphael Zulliger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53E47B59.3060700@indel.ch \
    --to=zulliger@indel.ch \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox