Re: [msysGit] Re: [PATCH] Add custom memory allocator to MinGW and MacOS builds

From: Johannes Sixt <j6t@kdbg.org>
Date: Apr 4, 2009, 06:35 UTC
Message-ID: <200904040835.24377.j6t@kdbg.org>
In-Reply-To: <49D6ED32.4000706@gmail.com>

On Samstag, 4. April 2009, Marius Storm-Olsen wrote:

Show 13 quoted lines

> Pat Thoyts said the following on 03.04.2009 23:12:
> > The difference on Windows Vista is that the low fragmentation heap
> > is the default memory allocator. On Windows XP you need to enable
> > it specifically for an application. So a possible alternative to
> > this is just to enable the low fragmentation heap. (done via
> > GetProcessHeaps and HeapSetInformation Win32 API calls).
>
> I know about the low-fragmentation heap, but given that it was only
> supported on XP and up (and given that I also had MacOSX in mind when
> considering a custom allocator; see MacOSX got 12% itself ;-), I
> didn't even consider it.
> Thanks for clearing up the differences on the Vista and XP benchmarks
> though! Makes sense.

Wouldn't a GetProcessHeaps/HeapSetInformation solution add much less code, even with a runtime check whether the feature is supported?

The improvement that you observed is in a rather special area (repack). How is the improvment in day-to-day tools:

- procelains used on command line: git-status, git-add, git-commit, git-diff, 
git-log, perhaps even local git-fetch.

- plumbing used by guis: git-diff-files, git-diff-tree, git-log, git-rev-parse

- I'm not even mentioning git-am, git-rebase, because here the time sink is 
the fork emulation.

I doubt that the improvement is equally great, and it will perhaps vanish in the noise. 7000+ LOC is a bit much in this case, don't you think so?

BTW, I assume that the Boost license is compatible with GPL. But did you check that?

-- Hannes