Hello Tomifei,
On 2026-02-07 14:00, Timofei Zhakov wrote:
[OpenSSL] However, I think there are some disadvantages to
using it. [...]
Performance optimizations may not be the only consideration here.
Portability is the other major one, hence the usage of APR. OpenSSL then
is already an optional dependency, and a widely used one at that -
assuming that most users are expecting support for TLS. Portability by
extension also includes the availability of the package in your target
OS distributions.
This is how I decided to try out and collect those optimised digest algorithms
into a separate and standalone project.
Acknowledging the effort (as in: "cool by default")!
Can you somehow quantify the expected performance gain based on
realistic svn operations? I understand that the digest operation itself
may be optimized. It would be interesting to know how that measures in
relation to all other typical operations including network and IO. (If
you posted this elsethread I can read that first.)
I would like to propose the idea of using it as a checksum backend in
Subversion. I have attached a patch that adds support for it.
What do you think?
I feel at this point I should call out (lib)nettle, with assembly
implementations for most if not all digests you implemented. It is
widely deployed - are you aware of it?
I see that your patch plugs your library into existing optional
facilities (apr/bcrypt), so it is also optional and unlikely to break
existing things. The rest of the consideration would be complexity for
maintenance and the increase in the testing matrix vs. the potential gain.
[1] https://github.com/rinrab/xdigest
I sent some general build fixes as you saw.
--
Nit: try "-- " with a space.
Andreas
