Re: Scm_sloppy_assq mostly fixed, still real slow

[Jan Nieuwenhuizen <janneke at gnu dot org>]

On Wednesday, 14 June 2000, Mikael Djurfeldt writes:

> How are you using scm_protect/unprotect_object?

Mainly for keeping smobified C++ objects alive.

> 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.

Ah, ok.

> While this *could* be the explanation, it could very well be something
> else.

That's most certainly the explanation.

I guess that this new profiling output:

-----------------------------------------------
                0.15    1.43  781175/17152144     scm_hash_fn_ref [327]
                3.20   30.06 16370969/17152144     scm_hashq_get_handle [43]
[42]     7.2    3.35   31.50 17152144         scm_hash_fn_get_handle [42]
               29.09    0.00 17152144/18853468     scm_sloppy_assq [47]
                2.40    0.00 17152144/17834292     scm_ihashq [242]
-----------------------------------------------
                0.43   16.61 8173030/16370969     scm_protect_object [66]
                0.43   16.66 8197939/16370969     scm_unprotect_object [67]
[43]     7.1    0.86   33.26 16370969         scm_hashq_get_handle [43]
                3.20   30.06 16370969/17152144     scm_hash_fn_get_handle [42]
-----------------------------------------------

tells me that indeed most all scm_sloppy_assq calls originate from
scm_un/protect_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.

Sorry, I'm not too deep into smobs.  (In our current setup) We can't use
stack space, or if the suggestive name does what it suggest,
scm_permament_object.  While most smobs live very long, they don't
live permanently.  What is protection by bindings?  Sorry for my
ignorance.

> How do you use these functions in Lilypond?

Typically upon construction(or soon thereafter)/destruction of C++
objects that are stored as SCMs.  In particular, all graphical items
in the backend that are to be typeset, are home-made smobs.  In the
case of the Coriolan, we have about 140 000 of those that make up the
entire score.  Before, these were all plain C++ objects, but we're
moving towards having all data (members) in scm.  When the score has
been written, LilyPond (the same process) may process another score,
or process the original input into another output format (eg, midi).

Of course, you're more than welcome to have a look at

    ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/development/lilypond-1.3.59.tar.gz

or thereabouts.

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org