> On May 1, 2015, 11:11 a.m., Rafael Schloming wrote: > > I have mixed feelings about this sort of change in general. I don't like > > making the code more complicated without some evidence that it will have a > > measurable impact, particularly with code that is already quite dense and > > subtle such as this. Do we have more than just conjecture in this case, > > e.g. is this a well known technique, or have we measured the effect? > > > > It's plausible to suggest that the benefit of this change may be limited > > since the resizing heuristics that control the load factor of the map will > > be working against the likelyhood of it ever triggering. I also suspect > > that soft deletes along with amortized rehashing would yield a much better > > optimization and render this one all but inert.
Conjecture by me. Do we have any performance benchmarks that could measure the impact of changes like this? - Alan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/33750/#review82242 ----------------------------------------------------------- On May 1, 2015, 9:59 a.m., Gordon Sim wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/33750/ > ----------------------------------------------------------- > > (Updated May 1, 2015, 9:59 a.m.) > > > Review request for qpid, Alan Conway, Andrew Stitcher, and Rafael Schloming. > > > Repository: qpid-proton-git > > > Description > ------- > > This implements the optimisation suggested by Alan. If the next entry in a > chain after the one being deleted is in the cellar (i.e. is non-addressable), > then there is no need to rehahs, that next entry can simply be copied into > the slot being deleted,and the next slot can be freed. > > > Diffs > ----- > > proton-c/src/object/map.c 2e3b157 > > Diff: https://reviews.apache.org/r/33750/diff/ > > > Testing > ------- > > The second unit test covers this case (as well as some others). My stress > testing has also shown no issue with it. > > > Thanks, > > Gordon Sim > >
