On 2020/04/11 11:36:16, hanwenn wrote: > On Sat, Apr 11, 2020 at 1:05 PM <mailto:jonas.hahnf...@gmail.com> wrote: > > > > On 2020/04/11 05:37:39, hanwenn wrote: > > > > In addition, I don't think that it is used to a degree where it > > would > > > significantly affect LilyPond's performance. > > > > > > It is not yet. > > > > > > My plan is to plugin this into Grob and Prob and see if there is a > > measurable > > > speed improvement. If there is none, it's likely that your double > > indexing > > > scheme will also not bring much. > > > > I'd strongly suggest we have numbers first before introducing ~300 lines > > for a custom hash implementation. It's good to have the implementation > > available early (I haven't looked at it yet), but I think it should only > > be merged with strong evidence that it's worth it. > > I'm not opposed to this, but in the same vein, I think we should then > hold off on merging David's reorganization of the property accesses in > https://codereview.appspot.com/573670043/ > > -- > Han-Wen Nienhuys - mailto:hanw...@gmail.com - http://www.xs4all.nl/~hanwen
As I already said there: that change is purely syntactically as of that patch, the difference in appearance is not odious, and it allows for parallel development of one or more different implementations without ongoing merge conflicts. It doesn't favor any particular approach, merely reorganises the macro call in a manner where more information is available to the implementation of the macro. This is not "in the same vein" but more like the aorta. -- David Kastrup https://codereview.appspot.com/559790043/