Den tis 30 dec. 2025 kl 17:36 skrev Timofei Zhakov <[email protected]>:
> I appreciate all suggestions and opinions mentioned. But let me > clarify why I made those design choses a bit more. > > - Yes, it is faster because OpenSSL uses specific assembly > instructions of modern CPUs. > Agree, if built with a specific ASM flag. (We also saw this in TortoiseSVN, I think it was Evgeny who suggested it initially). > > - I believe that this optimization should *not* be done in APR > (apr-util to be more specific). Most of its users don't want it to be > crazy fast. They would most probably choose a more portable, simple, > and lightweight implementation instead. Subversion, on the other hand, > will generally work faster as checksumming improves. > A discussion of what APR and APR users want is probably out of scope /here/ but should go to dev@apr. Agree that Subversion would benefit from a faster checksumming implementation. > - There is a public structure for checksum context data in APR so this > might be problematic to adapt a different implementation. > Fair point - and this MAY be a dealbreaker for the APR project. But I'd like to see it discussed on dev@apr first. > - Httpd barely uses it and it's never critical to the overall > performance part. I could find that only mod_lua and password > authentication support uses SHA1 from APR. It's not an optimization > whenever this code is called once a decade for like <20 bytes of data. > Is there a significant downside to use OpenSSL? Ie, assuming that APR is build with OpenSSL support and using OpenSSL's checksumming algorithm. Will there be a significant additional time spent on loading the OpenSSL library if it is only used for calculating a checksum? I assume there are other project using APR behind the scenes. > - I discovered a much more convenient cryptography library (AWS-LC > [1]). It's basically a fork of OpenSSL, but with simplified > everything. We might make an interface for it as well. > Nice - but separate discussion. > > - It's a great idea to "steal" optimized hash implementation, so we'd > get that performance boost without requiring any third-party > libraries. I think AWS-LC would be more suitable for this purpose > because it bundles pre-generated assembly sources whereas OpenSSL > needs perl for that. > I would not want to copy an existing implementation (including significant ASM code). That would open us up for a major investment in maintenance. I think we should keep the project simple by interfacing with external libraries that do this better, in line with the Unix philosophy of doing one thing and doing it well. Cheers, Daniel > Therefore, I suggest we move towards optimizing hashes in Subversion > specifically. I don't like OpenSSL either, but it's a good enough > direction to start. > > [1] https://github.com/aws/aws-lc > > -- > Timofei Zhakov >
