qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan Conway" <acon...@redhat.com>
Subject Re: Review Request 33750: Optimisation of map entry deletion
Date Mon, 04 May 2015 19:39:01 GMT


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


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