Bug 15412 - Performance regression in "info {func,var,types} foo" (mostly info types).
Summary: Performance regression in "info {func,var,types} foo" (mostly info types).
Status: NEW
Alias: None
Product: gdb
Classification: Unclassified
Component: symtab (show other bugs)
Version: unknown
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: performance
Depends on:
Reported: 2013-04-27 21:34 UTC by dje
Modified: 2015-02-20 23:32 UTC (History)
6 users (show)

See Also:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description dje 2013-04-27 21:34:32 UTC
In a large program I'm seeing a performance regression in
info {func,var,types} ^foo::(anonymous namespace)

For example, in 7.5 it takes 2 seconds, in 7.6 and cvs head it takes ~300 seconds.

I think there are multiple factors here because a comparison of gdb before/after the type-pretty-printing patches of ~2012-11-12 I only see a perf degradation from 2 seconds to 150 seconds.  So something after that is then slowing things down from 150s to 300s.

Data point: If I hack "info {func,var,type}" to set type_print_options.raw = 1,
I get most (maybe all) the performance back.

It seems like we want type-pretty-printing for info types, but the performance cost can be high.  Thus I'm thinking "info {func,var,types}" should have a /r (raw) option.

OTOH, a lot of the cost can be reduced, I think, by caching lookups: the same symbol is processed many(!!!) times.  The caching could be at multiple levels (e.g., more than just simple symbol lookups), I'm not sure what's the best one yet.
Comment 1 Tobias Hunger 2013-05-17 10:09:22 UTC
I see the same issue debugging C++ applications using GDB 7.6 with Qt Creator. 

Getting a list of local variables and their values after hitting a breakpoint takes at least 10s where it is almost instantaneous in GDB 7.5.

This time can increase dramatically (> 2 min!) with the complexity of the code containing the breakpoint.

GDB 7.6 is not usable in this setup, I had to revert back to GDB 7.5. I would seriously consider raising the importance of this regression.
Comment 2 asmwarrior 2013-05-24 13:49:03 UTC
I see the same regression here under MinGW GDB CVS 2013-05-24, when I try to run the command "ptype wxEvent", then GDB goes to hang/loop for a long time(I just kill it), but for a GDB cvs build 2012-08-17, the response is less than a second.
Comment 3 asmwarrior 2013-05-24 14:33:41 UTC
As DJE said, the workaround looks like below:
 gdb/typeprint.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdb/typeprint.c b/gdb/typeprint.c
index 4e70593..6e62922 100644
--- a/gdb/typeprint.c
+++ b/gdb/typeprint.c
@@ -62,7 +62,7 @@ const struct type_print_options type_print_raw_options =
 static struct type_print_options default_ptype_flags =
-  0,				/* raw */
+  1,				/* raw */
   1,				/* print_methods */
   1,				/* print_typedefs */
   NULL,				/* local_typedefs */

Adding a command like below should be better I think:
"show print type raw"
"set print type raw"

We have already "set print type method" and "set print type typedef"
Comment 4 asmwarrior 2014-06-16 01:39:09 UTC
Some test result: GDB GIT HEAD python enabled, but without the hack patch of comment 3). When debugging a large Codeblocks project with debug wxWidgets library. "ptype wxEvent" returned instantly, and "info types wxEvent" takes about 60 seconds. But compared with my comment 2, it looks like the performance has improved.