----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/33750/#review82242 -----------------------------------------------------------
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. - Rafael Schloming 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 > >
