On Fri, Aug 28, 2020 at 08:29:44AM -0700, Elijah Newren wrote: > > It may also be a sign that we should be growing the hash more > > aggressively in the first place. Of course all of this is predicated > > having some benchmarks. It would be useful to know which part actually > > provided the speedup. > > Your thoughts here are great; I also had another one this past week -- > I could introduce a hashmap_partial_clear() (in addition to > hashmap_clear()) for the special usecase I have of leaving the table > allocated and pre-sized. It'd prevent people from accidentally using > it and forgetting to free stuff, while still allowing me to take > advantage. But, as you say, more benchmarks would be useful to find > which parts provided the speedup before taking any of these steps. Yeah, having a separate function to explicitly do "remove all elements but keep the table allocated" would be fine with me. My big desire is that clear() should do the safe, non-leaking thing by default. -Peff
