Re: [gnugo-devel] weird performance problem

[Paul Pogonyshev]

Arend wrote:
> 
> Paul wrote:
> 
> > > Tracking back some spurious 50% slowdowns for regression runs,
> > > I found out (with oprofile) that 50% of CPU time was spent in libc.
> 
> (...)
> 
> > > Profiling through timer interrupt
> > > samples  %        symbol name
> > > 6769     86.3393  __mcount_internal
> > > 665       8.4821  mcount
> > > 189       2.4107  __i686.get_pc_thunk.bx
> > > 170       2.1684  memset
> > > 27        0.3444  memcpy
> > > 6         0.0765  _int_malloc
> > > 3         0.0383  __GI___mbrtowc
> > > 2         0.0255  _int_free
> > > 1         0.0128  __GI___gettimeofday_internal
> > > 1         0.0128  __GI__dl_mcount_wrapper_check
> > > 1         0.0128  __malloc
> > > 1         0.0128  __realloc
> > > 1         0.0128  _int_realloc
> > > 1         0.0128  _nl_explode_name
> > > 1         0.0128  _nl_make_l10nflist
> > > 1         0.0128  index
> > > 1         0.0128  strlen
> > 
> > This is not very helpful.  Can't say anything without call tree.
>
> [...]
>
> Actually, it (partially) turned out to be a sillyness of mine: I
> had somehow carried around -pg in the Makefiles, and mcount() seems
> to be the collecting point for gprof data.

You should not edit `Makefile's directly.  This is too error-prone
(and your example confirms).  You can just do

        make -s clean
        make -s CFLAGS='-O2 -pg'

Then, once you don't need profiling information, just clean again and
rebuild with default CFLAGS.

> Still, I got only <15% of CPU time for a gnugo that I had explicitly
> compiled with -pg and -lc_p.

I don't understand.  Do you mean the profiler eats 85% of CPU time?
And what is the `c_p' library?  The profiler library?

Paul