Re: [PATCH v2 09/20] merge-ort: record stage and auxiliary info for every path
- From
Derrick Stolee <stolee@gmail.com>
- Date
- Nov 12, 2020, 18:23 UTC
- Message-ID
- <dbc8eddf-a6ef-b087-7714-0dc03f5b32a7@gmail.com>
- In-Reply-To
- <CABPp-BHCqD8yS_4t7ztL2+FxjPCZ9Meq97VfRhnDRwCjLpdSzg@mail.gmail.com>
On 11/11/2020 5:06 PM, Elijah Newren wrote:
Show 25 quoted lines
> On Wed, Nov 11, 2020 at 10:16 AM Elijah Newren <newren@gmail.com> wrote: >> This was the whole point of the strmap API[1] I recently added -- >> provide a hashmap specialized for the case where the key is a string. >> That way I get fast lookup, and relatively fast resize as the hash >> only contains pointers to the values, not a copy of the values. >> >> Is your concern that allocating many small structs is more expensive >> than allocating a huge block of them? If so, yes that matters, but >> see the mem_pool related patches of the strmap API[1]. >> >> [1] https://lore.kernel.org/git/pull.835.v5.git.git.1604622298.gitgitgadget@gmail.com/ > > > I just re-read what I wrote, here and below...and I need to apologize. > I tend to write, edit, revise, and repeat while composing emails and > the end result of my emails doesn't tend to reflect the path to get > there; I looped through that cycle more times than most on this email. > But, even worse, I added in a sentence or two that just shouldn't be > included regardless. I think in particular this one sounds extremely > aggressive and dismissive which was not at all my intent. > > I find your reviews to be very helpful, and I don't want to discourage > them. Hopefully my comments didn't come across anywhere near as > strongly as they did to me on a second reading, but if they did, I'm > sorry.
I did not feel any animosity. Your response was just so involved that I didn't have time to respond in kind. I hope to do so later today.
The short version of my reply is "You know more about this than me, and I appreciate the additional detail."
Thanks, -Stolee