On 2020/04/12 10:35:24, hanwenn wrote: > On Sat, Apr 11, 2020 at 3:55 PM David Kastrup <mailto:d...@gnu.org> wrote: > > >> You haven't understood the scheme. A grob only contains the properties > > >> seminal to its type. That's why there is a double indirection. A full > > >> array of 416 entries is needed per grob _type_, not per grob. > > > > > > I still don't see why this requires an overall overhaul of the > > > internal calling convention. You can have a global registry of symbol > > > => uint16 (numbering all the symbols), > > > > It would be pointless to have a single registry for music properties, > > grob properties, stream event properties, and context properties, thus > > significantly blowing up the second-level indexing tables and making for > > a large number of cache misses. > > there are 400 grob properties, and about 800 properties in total > (including music and context). 400 requires 9 bits, 800 requires 10 > bits. It doesn't appreciably change the problem size.
Populating arrays densely or sparsely makes a large difference in how well they fit caches. However, this is completely irrelevant since this patch does not, I repeat _not_ enforce any particular implementation. All that it does is provide the macros with more complete information and thus enables implementations that are not crippled down by having macros pretend to be able to deal with overload resolution. That you don't feel that you are able to make use of that change does not mean that you are the only developer who should be allowed to work on such problems and consequently should be able to block off any attempt of restructuring the source code in a manner that allows other developers to more easily experiment with other approaches without having to constantly resolve rebase conflicts because a design decision unsuitable for refactoring is kept in place for no good reason. You'll find that we have had several restructurings of macro call locations in the past years in order to facilitate refactorings, some with more, some with less success and permanent impact. In general, the developers proposing them had reasonable expectations for the directions those changes would open for them, and reasonable consideration for the impact on others. Please keep in mind that LilyPond, as it stands now, is a colloborative project. Accommodating the work of others to proceed, given reasonable goals and impact, is therefore a necessity. A stance that amounts to "I cannot make that work, so we shouldn't move in a direction where you could try" is not really useful for a colloborative effort of developers with equal standing. I had several other proposals of syntax that would provide required information to the macros in case, but this is the least intrusive one that retains some flavor of overloading. https://codereview.appspot.com/573670043/
