Re: Scm_sloppy_assq mostly fixed, still real slow

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Jan Nieuwenhuizen <janneke@gnu.org> writes:

> Ok, with scm_unprotect_object fixed, 1.3.4 and 1.3.5 are comparable
> wrt execution times (1.3.5 is a lot better on memory usage).  However,
> with my fixed 1.3.5, I still see quite some time in scm_sloppy_assq,
> (half a minute), where I hardly see any time for 1.3.4 (half a second).
> Other entries look similar.

How are you using scm_protect/unprotect_object?

Let's assume that they are frequently used.  In Guile 1.3.4, their
implementation was simple, with very good performance if
scm_protect/unprotect_object are used in a "block-structured" way:

  scm_protect_object (...)
  ...
  scm_unprotect_object (...)

But the implementation had bad worst-case performance (O (N)).

In 1.3.5, the implementation has changed to a worst-case O (1) (or
rather O (N / M) where M is big), but with a larger constant factor,
involving scm_sloppy_assq.

While this *could* be the explanation, it could very well be something
else.  Is it possible for you to check how much time of the
scm_sloppy_assq time belongs to scm_protect_object?  If your profiler
can't tell you directly, you could clone scm_sloppy_assq using a
different name, and use this new function in
scm_protect/unprotect_object.

Generally, I consider using scm_protect/unprotect_object bad style.
It's almost always possible to structure the application in a way that
you don't need them.  Most objects can be protected by the fact that
they are referred from bindings or from the C stack.  The rest can
usually be protected by locations protected by scm_permament_object or
by being referred from data structures which are themselves
protected.

How do you use these functions in Lilypond?