Re: Surprising use of memory and time when repacking mozilla's gecko repository
- From
- Eric Wong <e@80x24.org>
- Date
- Jul 4, 2019, 12:04 UTC
- Message-ID
- <20190704120411.2dlzdlsooob4dc7k@dcvr>
- In-Reply-To
- <20190704100530.smn4rpiekwtfylhz@glandium.org>
Mike Hommey <mh@glandium.org> wrote:
> I'm puzzled by the fact writing objects is so much faster with 1 thread.
I/O contention in the multi-threaded cases?
"public-inbox-index" (reading from git, writing to Xapian+SQLite) on a dev machine got slow because core count exceeded what SATA could handle and had to cap the default Xapian shard count to 3 by default for v2 inboxes.
As for memory use, does git use the producer/consumer pattern for malloc+free so free happens in a different thread from the malloc?
Because current versions of glibc gets pathological with that case (but I have a long-term fix for it):
https://public-inbox.org/libc-alpha/20180731084936.g4yw6wnvt677miti@dcvr/T/ Only locklessinc malloc seemed OK in the IPC department (But I haven't kept up with jemalloc, tcmalloc developments in years)