Re: Reimplement Scheme_hash_table using linear probing. (issue 559790043 by address@hidden)

[dak]

On 2020/04/11 11:36:16, hanwenn wrote:
> On Sat, Apr 11, 2020 at 1:05 PM <mailto:address@hidden>
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:address@hidden -
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/