qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rafael Schloming" <...@apache.org>
Subject Re: Review Request 33750: Optimisation of map entry deletion
Date Fri, 01 May 2015 11:11:57 GMT

-----------------------------------------------------------
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
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message