On 30. 12. 25 18:36, Daniel Sahlberg wrote:
Den tis 30 dec. 2025 kl 17:36 skrev Timofei Zhakov <[email protected]>:
[...]
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?
Process startup is not an issue here, especially on ELF platforms that
most likely have libcrypto already loaded in memory. It's slower on
Windows, but everything is anyway.
I assume there are other project using APR behind the scenes.
As I said, there are potential issues if Serf, Subversion and APR all
use different versions of OpenSSL. This used to be a quite serious issue
on Windows back in the day, less so now when everything is a
side-by-side assembly, and it's even less of an issue with vcpkg and
similar available.
I think those issues are less now with OpenSSL 3, but can't be sure. In
most environments, with platforms maintainers taking care of package
versions, there should be no problems.
[...]
- 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.
Think of it as another SQLite amalgamation or utf8proc. It's not
/that/ much work once it's imported and spliced into the builds.
(Which reminds me, someone should upgrade the built-in utf8proc before
the next release. That, or we should make it a mandatory dependency,
it's not a rare beast any more, even on Windows.)
-- Brane
