Switch Git for Windows to using mimalloc instead of nedmalloc

[dscho]

As per the very author of nedmalloc, "nedmalloc is pretty much EOL". In other words, it is unmaintained since 2014.

Nevertheless, we rely on nedmalloc in Git for Windows because the MINGW toolchain is stuck with an MSVC runtime that comes with a malloc() implementation that is not quite up to par.

I tested with git repack -q -d -l -A --unpack-unreachable=2.weeks.ago in a partial clone of the Linux source code, which seems to exercise the malloc() function a lot. Here is the table for the gcc builds:

	MIMALLOC	MIMALLOC2	DEFAULT	NEDMALLOC
run #1	943.426	968.415	994.807	995.383
run #2	978.5	970.002	974.177	952.179
run #3	939.709	970.511	974.364	943.253
run #4	959.811	954.267	977.028	963.043
run #5	954.605	962.94	985.003	980.468

Here, MIMALLOC2 is run with MIMALLOC_RESET_DELAY=1, MIMALLOC_EAGER_COMMIT=0 and MIMALLOC_RESET_DECOMMITS=1, which were recommended in mimalloc's issue tracker as potentially speeding up certain workloads.

The mimalloc column is the fastest on average, and in three of the five rows. Run #2 seems to have been an outlier, and in row #4 the non-default allocator times are all close by. Which suggests that mimalloc is a clear winner there.

For the MSVC builds, the outcome is a lot more unclear:

	MIMALLOC	MIMALLOC2	DEFAULT	NEDMALLOC
run #1	598.378	604.567	565.719	613.449
run #2	590.753	586.93	569.855	562.625
run #3	572.65	575.857	595.014	575.253
run #4	555.739	554.052	553.083	609.74
run #5	635.621	615.021	606.976	583.35

First of all, the numbers here all seem lower, but this is a separate run on separate build agents at a different time, under a different load, so it is safer to not compare the gcc vs MSVC numbers here (that'll be a fun project on its own, at some stage). Point in case: these numbers are smaller than with a similar benchmark I've run before where no unreachable objects were unpacked. This makes no sense and is probably caused by the variance in the load of different build agents (which is why I run these experiments as much on the same build agent as possible, to have somewhat of an apples-to-apples comparison).

The next thing to note is that the default allocator is pretty much the clear winner here, and mimalloc fares the worst with default parameters, closely followed by nedmalloc and by mimalloc2.

The strangest thing about these conclusions is that contrary to my findings almost 3 years ago, the default allocator does not perform terrible in these benchmarks. Obviously I do not have the very same linux repository I used for testing anymore (neither the machine on which I ran those tests, nor that machine's successor). But the findings were very clear back then, something along the lines of default allocator runs performing 1.5x - 2x slower than nedmalloc, and even mimalloc slightly but noticeably slower than nedmalloc.

So I tried to repeat the benchmark based on the same Git revision as I had done almost 3 years ago, 144cb18. Skipping the MSVC builds altogether (because I could not quickly make them compile without having to investigate some link issues), here are the gcc numbers:

	MIMALLOC	MIMALLOC2	DEFAULT	NEDMALLOC
run #1	1042.267	1047.36	1078.417	928.548
run #2	999.148	1027.712	1146.847	1158.742
run #3	1125.634	1251.313	1285.239	1234.397

In contrast to my original test 3 years ago (which was based on mimalloc v1.1.0, see 498594b), I used mimalloc v2.0.6 (i.e. the latest available version), which is probably the reason why it performs better now than my recollection would have suggested. However, this benchmark finally seems to recapitulate to some extent what I had seen back then, i.e. that nedmalloc performed so much better than the default system allocator (I interpret run #1 as an outlier, kind of "warming up the caches").

We will have to be a bit careful comparing these numbers when looking at different workflow runs (or even different matrix jobs), and not draw too strong conclusions, because those are numbers obtained by running on build agents, whose load is naturally very variable and therefore not really suitable for performance benchmarking.

Having said that, I feel confident to draw the following conclusions:

• Git's code changed substantially in the past 3 years, making repack performance a lot more independent from the performance characteristics of the malloc() implementation that is used.
• mimalloc is a suitable replacement for nedmalloc for the gcc builds, possibly even slightly improving the performance (but the numbers are too inconclusive to say for certain).
• Due to nedmalloc being woefully unsupported (and Git not even using the latest available version because of a similar performance hit as with mimalloc v1.1.0 when I had originally measured it), and due to mimalloc having matured even further in the past 3 years, we should switch Git for Windows over from nedmalloc to mimalloc.

[derrickstolee]

I have a few questions that might clarify some of my understanding, but overall I think this is ready.

[jeffhostetler]

Looks good to me!