Re: marking overhead, and on the cost of conditionals in hot code

[ludo@gnu.org (Ludovic Courtès)]

Hello!

Andy Wingo <wingo@pobox.com> writes:

> I dropped into cachegrind, and it tells me thing about scm_gc_mark in a
> simple guile -c 1 run:
>
>       .  void
>       .  scm_gc_mark (SCM ptr)
> 794,344  {
> 155,170  => ???:0x00024917 (77585x)
> 198,586    if (SCM_IMP (ptr))
>       .      return;
>       .    
> 513,038    if (SCM_GC_MARK_P (ptr))
>       .      return;
>       .  
>  84,580    if (!scm_i_marking)
>       .      {
>       .        static const char msg[]
>       .  	= "Should only call scm_gc_mark() during GC.";
>       .        scm_c_issue_deprecation_warning (msg);
>       .      }
>       .  
>  42,290    SCM_SET_GC_MARK (ptr);
>  63,435    scm_gc_mark_dependencies (ptr);
> 2,666,432  => /home/wingo/src/guile/vm/libguile/gc-mark.c:scm_gc_mark_dependencies (5222x)
>     704  => /usr/src/debug////////glibc-20081113T2206/elf/../sysdeps/i386/dl-trampoline.S:_dl_runtime_resolve (1x)
> 595,758  }
>
>
> I think that the items on the left are cycle counts, and are of relative
> importance. The => lines are the cumulative costs of the subroutines.

This is actually the output of Callgrind, and the left column is
instruction reads ("Ir"), which is not directly equivalent to the cycle
count, especially on a CISC arch (it's nevertheless a good
approximation, I'm just nitpicking ;-)).

> The salient point for me is that the scm_i_marking check slows down
> this function by about 10%! Also, that the majority of the time in this
> function is in the SCM_GC_MARK_P line.
>
> If I thought that we'd keep our GC, I would work at inlining this
> function, i think.

But it's a macro, isn't it?

Thanks,
Ludo'.