From: Joey Hess <joeyh@joeyh.name>
Date: Mon, 15 Feb 2021 16:36:45 +0000 (-0400)
Subject: perf note
X-Git-Tag: archive/raspbian/10.20250416-2+rpi1~1^2~98^2~16
X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=178dc5ea6cf00de6ffc88474f8905b0dbfb67b04;p=git-annex.git

perf note

Following up to f44d4704c638e2fdb48dd0667809b16fac377b5b,
I tried making updateIncremental pure, avoiding the IORef overhead.
That did not improve speed though. It did complicate the interface since
thunks needed to be forced to avoid leaking memory. So am not going with
that change.

Looking at Crypto.Hash.hashUpdate, it copies a byte array on each call,
compared with hashlazy that only uses 1 copy for the whole bytestring.
That could well explain a lot of the overhead discussed in the
abovementioned commit. Don't see any way to improve that while hashing
incrementally, except using bigger chunks should reduce its overhead.
Since 10x larger chunks did not, I'm kind of puzzled if it's really
what's affecting performance.
---