Re[2]: Setting a variable is very slow.

[jagorak <jagorak@wp.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
lang ada).

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:

   Package.Data.DataMember

the 'mangled' C names would be:

   package__data.datamember

(all lower-case).

(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).

Regards,
Jan
   




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.