Performance problems between gcc 12.2 and 13

[Carlos O'Donell]

On Tue, Jul 17, 2012 at 5:18 PM, Judd Montgomery <judd@engineer.com> wrote:
>> If you step into the function which is the final routine selected to
>> perform the string operation?
>>
> Is this what you are asking?

Yes.

> $ gdb ./loop.12
> GNU gdb (GDB) 7.0-ubuntu
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /home/jmontgomery/loop.12...done.
> (gdb) break strptime
> Breakpoint 1 at 0x400548
> (gdb) run
> Starting program: /home/jmontgomery/loop.12
>
> Breakpoint 1, 0x00007ffff7af85c0 in strptime () from
> /opt/glibc-2.12.2/lib/libc.so.6
> (gdb) step
> Single stepping until exit from function strptime,
> which has no line number information.
> 0x00007ffff7af86c0 in __strptime_internal () from
> /opt/glibc-2.12.2/lib/libc.so.6
> (gdb) step
> Single stepping until exit from function __strptime_internal,
> which has no line number information.
> 0x00000000004006d5 in main ()
> (gdb)

Is this function actually consuming most of your time?

You need to profile your program, either with a proper profiling tool
or simply using RDTSCP (see
http://download.intel.com/embedded/software/IA/324264.pdf).

The function __strptime_internal hasn't changed in any significant way
since 2007, so if __strptime_internal is taking up time in your
profile it might be that the compiler is doing something different.

Next steps:
- Profile your run.
- Find out which functions are taking up time.
- Look into those.

Cheers,
Carlos.