On Sun, Feb 8, 2026 at 3:33 PM Andreas Stieger <[email protected]> wrote: > > Hello Tomifei,
New one :) > > 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 should not complicate packagers' lives if they don't want to use this feature. It's completely optional. Here openssl might even lose in terms of portability due to its robust design nature. > > 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.) Initial performance benchmarks have been noted in the commit message as openssl backend was added. r1930949: [1]. This consisted of 8-times improvement of general hash processing (which also gives the same boost for svn status with pristeneless working copies). Also this introduces 2-times improvement of svn checkout (over file:// protocol). > > 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 haven't heard about this library. It's pretty good though. I didn't test it, but I guess that it might have slightly worse performance. Also it's licensed under LGPL. > 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. Thanks! I appreciate that! [1] https://lists.apache.org/thread/o38r06vg08pyzzy35bfgg8ooovphsxss -- Timofei Zhakov
