On Fri, Oct 30, 2020 at 12:31:13PM -0700, Elijah Newren wrote: > > I think we could fall back to a FLEXPTR when there's no mempool (or even > > when there is, though you'd be on your own to reimplement the > > computation parts of FLEXPTR_ALLOC). I'm not sure how ugly it would end > > up. > > Yeah, we'd need a mempool-specific reimplementation of FLEXPTR_ALLOC > with the mempool, and just avoid using it at all whenever > strdup_strings was 0. Seems slightly ugly, but maybe it wouldn't be > too bad. I could look into it. It looks like you went this route (fall back to FLEXPTR) in the re-roll you posted. I haven't looked at it carefully yet, but I suspect it will be just fine to me (I probably would have accepted "no, it makes the code too ugly; if you want efficiency use a mempool" as well, but I'll see how ugly it turned out. ;) ). > Anyway, at the time I > put the mempool into strmaps and made use of it in relevant places, > one of my rebase testcases saw an almost 5% reduction in overall > execution time. I'm sure it would have been over 5% if I had > reordered it to come after my final rename optimization. Thanks, it's nice to have a ballpark like that. It might be worth putting it into the commit message, even if it's hand-wavy: This seemed to provide about 5% speedup for some rebase test cases I ran. Unfortunately you can't just time this commit and its parent, since we aren't yet actually using strmap in the code yet. But again, I think the main value of that is during review, so if it doesn't make it into the commit message, I'm OK. -Peff
