Bug 9884 - Inefficient code in function default_print_registers_info
Summary: Inefficient code in function default_print_registers_info
Status: ASSIGNED
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: 6.8
: P3 enhancement
Target Milestone: 6.8
Assignee: Thiago Jung Bauermann
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-23 16:39 UTC by richard.stuckey
Modified: 2010-09-25 17:31 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description richard.stuckey 2009-02-23 16:39:59 UTC
In the function default_print_registers_info in the file infcmd.c, there is the code

      /* If the register name is empty, it is undefined for this
         processor, so don't display anything.  */
      if (gdbarch_register_name (gdbarch, i) == NULL
          || *(gdbarch_register_name (gdbarch, i)) == '\0')
        continue;

      fputs_filtered (gdbarch_register_name (gdbarch, i), file);
      print_spaces_filtered (15 - strlen (gdbarch_register_name
                                          (gdbarch, i)), file);

i.e. the function gdbarch_register_name may be called up to four times for each
register; it would be better to replace this code with


      {
        const char* name = gdbarch_register_name (gdbarch, i);

        /* If the register name is empty, it is undefined for this
           processor, so don't display anything.  */
        if (name == NULL || *name == '\0')
          continue;

        fputs_filtered (name, file);
        print_spaces_filtered (15 - strlen (name), file);
      }
Comment 1 Thiago Jung Bauermann 2009-03-08 06:05:34 UTC
I just had a look at the implementation of gdbarch_register_name for some
architectures, and the function is quite efficient, normaly just a few compares
and an array access. Perhaps it's a bit more complex for arches which use a
target description XML, I didn't look much into it. But even then it doesn't
seem to me it would be a problem.

Are you having actual performance issues in GDB because of this? If not, I'd
like to just close this. Not that it would be difficult to apply the code
snippet you mention, but I wouldn't like to start a trend of having bugzillas
opened for cosmetic issues in the source code...
Comment 2 richard.stuckey 2009-03-09 11:14:29 UTC
No, no performance issue seen, the code just struck me as inelegant: computing
the same quantity four times instead of once.