On 2020/01/24 15:50:22, Dan Eble wrote:
> On 2020/01/24 15:17:02, dak wrote:
> > On 2020/01/24 14:11:59, Dan Eble wrote:
> > > On 2020/01/24 14:06:22, hanwenn wrote:
> > > > If the allocation cost becomes problematic, we can use another
hashmap
> > > instead.
> > >
> > > "We" could profile it and
On Jan 24, 2020, at 11:11, d...@gnu.org wrote:
>> Don't assume the hash function is perfect: create the table with more
> buckets,
>> say 2*size.
>
> I'd not do that. It's second-guessing the implementation. The size
> should be good as a hint. In particular if there are actual
> duplicates...
On 2020/01/24 15:50:22, Dan Eble wrote:
> On 2020/01/24 15:17:02, dak wrote:
> > On 2020/01/24 14:11:59, Dan Eble wrote:
> > > On 2020/01/24 14:06:22, hanwenn wrote:
> > > > If the allocation cost becomes problematic, we can use another
hashmap
> > > instead.
> > >
> > > "We" could profile it and
On 2020/01/24 15:17:02, dak wrote:
> On 2020/01/24 14:11:59, Dan Eble wrote:
> > On 2020/01/24 14:06:22, hanwenn wrote:
> > > If the allocation cost becomes problematic, we can use another
hashmap
> > instead.
> >
> > "We" could profile it and know before pushing whether it is worth
it.
>
> I
https://codereview.appspot.com/583390043/diff/551390044/lily/grob.cc
File lily/grob.cc (right):
https://codereview.appspot.com/583390043/diff/551390044/lily/grob.cc#newcode971
lily/grob.cc:971: int j = 0;
On 2020/01/24 15:17:13, dak wrote:
> vsize j = 0;
> :-)
Done.
https://codereview.appspot.com/583390043/diff/551390044/lily/grob.cc
File lily/grob.cc (right):
https://codereview.appspot.com/583390043/diff/551390044/lily/grob.cc#newcode971
lily/grob.cc:971: int j = 0;
vsize j = 0;
:-)
https://codereview.appspot.com/583390043/
On 2020/01/24 14:11:59, Dan Eble wrote:
> On 2020/01/24 14:06:22, hanwenn wrote:
> > If the allocation cost becomes problematic, we can use another
hashmap
> instead.
>
> "We" could profile it and know before pushing whether it is worth it.
I don't think that this is really performance-critical.
On 2020/01/24 14:06:22, hanwenn wrote:
> If the allocation cost becomes problematic, we can use another hashmap
instead.
"We" could profile it and know before pushing whether it is worth it.
https://codereview.appspot.com/583390043/
Reviewers: dak,
Message:
On 2020/01/24 13:29:34, dak wrote:
> Not sure about the speedup (we might have small sizes often enough
that the
> constant factor becomes relevant), but the code is quite a net win
with regard
> to obviously doing what it should do. It probably takes a whole lot
more
>
Not sure about the speedup (we might have small sizes often enough that
the constant factor becomes relevant), but the code is quite a net win
with regard to obviously doing what it should do. It probably takes a
whole lot more allocation calls, but at least the impact on memory is
just
10 matches
Mail list logo
