This is the mail archive of the
mailing list for the GDB project.
Re: Setting a variable is very slow.
- From: jagorak <jagorak at wp dot pl>
- To: Daniel Jacobowitz <drow at false dot org>, Robert Dewar <dewar at adacore dot com>
- Cc: gdb at sourceware dot org
- Date: Mon, 30 Apr 2007 21:05:31 +0100
- Subject: Re: Setting a variable is very slow.
- References: <email@example.com> <20070421134117.GA10446@caradoc.them.org>
- Reply-to: jagorak <jagorak at wp dot pl>
Thanks for the suggestions.
A colleague of mine did some testing using the -statistics option and
learned that setting variables are slow because of the ada mode (set
Switching to the "c" mode (set lang c) solves the problem.
More info below for those who are interested:
I had to resort to using mangled names (since in 'c' mode) , but they
did not occur to be problematic.
For a sample Ada type, say:
the 'mangled' C names would be:
(it will be more dificult if "Data" were to be type name).
Note: I'm using customized version of GDB (custom target) and I
realized that it may be that the 'plain' GDB works actually fine
(=fast) in that aspect. (Although I don't really know.)
I was trying to reproduce the problem on the 'plain' GDB (since
oviously customized version is not of your concern!) to see whether
the problem reoccurs. I created a very simple program with lots of
symbols in it. The target was 'exec' - everything worked fine. (no
significant delays). This is obviously not entirely representative
'test' since I feel the target may have impact here (regardless of any
customizations to GDB).
DJ> On Sat, Apr 21, 2007 at 01:43:25PM +0100, jagorak wrote:
>> I need to make hundreds of such assignments & calls. The problem is -
>> setting a single variable is very slow (in most cases it takes much
>> more time to set a single variable than to call a procedure, even if
>> the procedure is not very simple).
>> Any ideas why this is the case?
DJ> I know of some problems in this area, but it's not clear which one is
DJ> your problem here. Could you try building gdb with
DJ> --enable-profiling? It should generate a gmon.out. That might not
DJ> show the real problem; if you want to just build a debuggable version
DJ> and use oprofile, that might work better. It depends whether GDB is
DJ> eating CPU or being wasteful with ptrace operations.