Re: Quick question about grob interfaces

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Fri, Jul 27, 2018 at 10:45 AM David Kastrup <address@hidden> wrote:
>
>>
>> > The grob-interfaces are a means to group certain functionality (and
>> > respective properties.). Whether it's OK for two separate pieces code to
>> > both use the same property depends on the specific case.  I suspect this
>> > reuse happens a lot for generic properties such as #'dir (or was it
>> called
>> > #'direction?).
>> >
>> > That said, I don't fully understand your question. What do you want to
>> do?
>>
>> Basically put all properties of a grob into a vector with fixed
>> positions.  Treating each interface as one block could be interesting
>> from a C++ implementation standpoint but if multiple interfaces used in
>> the same grob can contain the same property, that's not really an option
>> since virtual inheritance from every single property (rather than
>> interfaces) would be a nightmare
>>
>
> A vector seems wasteful of memory to me, and hard to make work.

An alist requires an additional cons cell per value.  Each of them
requires to be traversed separately.

> one option is that could avoid the allocations here
>
> https://github.com/lilypond/lilypond/blob/de27422214f61101b306c25213ab34d1fd7c3474/lily/break-substitution.cc#L125
>
> is to use type information of properties, ie. annotate each property with
> info as to whether it can contain grob pointers. If not, there is no need
> to recurse into the property.

As far as I can see, even non-grob values will assume different values
under different break conditions, so they need to be copied as well
which requires recursion.

> It's risky though, because it will be impossible to enforce that
> people obey rules about what kind of things can be stored in what
> property.

The current implementation first finds all relevant grobs via the
systems, then does the break processing as far as I understand.  So
there is no risk involved regarding processing all pertinent grobs since
the processing is done anyway, and the rest is a matter of the copying
recursion which is necessary for non-grob values anyway.

> like governing enough of LilyPond's core time and memory needs for large
>> scores that restructuring the data accordingly from the current quite
>> alist-based approach does not seem amiss.  I'm just trying to figure out
>> how to best wire the C++ parts of that.
>>
>
> IIRC, the expensive parts is rearranging long lists of grobs (eg. splitting
> the grobs attached to a system spanner into the post-linebreak system
> spanners.
>
> It's not clear to me how the alist per se is a problem and how
> restructuring could fix that.

Creating copies should be faster, requiring only one allocation per grob
property set.  Accessing properties at fixed vector positions should
beat an alist search: even if you need to first hash a symbol to an
index, registered symbols could be converted to a linear index at
compile time via macro expansion with each grob _type_ having a vector
converting that linear index into a vector index to its personal
property table, using two vector lookups at run time and those can be
C++ vectors, meaning that the indexes never need to be SCM.

Of course, creating a grob in an engraver will be slower since the alist
needs to be first converted into the vector form.  Assuming that the
overrides continue being maintained as an alist.  While
Grob_property_info::updated () has to return an alist, it is called a
lot less often explicitly than grobs are being created.

-- 
David Kastrup