> On May 1, 2015, 1:29 p.m., Andrew Stitcher wrote: > > I see nothing wrong with the code. > > > > However I do tend to agree with Rafi that this makes the code more complex > > and even less easy to understand then it already was. > > > > A big help would be a block comment describing the implementation at the > > top of the file with text diagrams etc. > > > > Perhaps more important would be a description somewhere of the data > > structure invariants.
+1, to save time I'd suggest a comment pointing to http://en.wikipedia.org/wiki/Coalesced_hashing - then you only have to describe how this implementation differs, where the "cellar" is etc. rather than writing a paper on coalesced hashing - Alan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/33750/#review82247 ----------------------------------------------------------- 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 > >
