That's two years ago and the issues have been fixed. Think of it this way: OpenSSL 3.0 was a release that added new, cleaner APIs and deprecated older, uglier APIs, so the focus was on that and not performance, but they've since put effort back into performance.

And by the way: OpenSSL has always cared a great deal about the performance of their cryptographic primitives, but the issue you linked to is NOT about that but about a performance degradation that happened in the code that _loads_ and references cryptographic algorithms.

IMO it's pretty lame to link to that issue as symptomatic of bigger problems in the OpenSSL community. And I say that as someone who was fairly involved in that issue as a user (I'm not an OpenSSL dev). It borders on the dishonest. How about giving them some accolades for responding to the issue, engaging the user community, and addressing the problem satisfactorily?

And as for them not having all the hardware that users run on, the perf issue in question did not require any particular hardware. The issue was systemic and easily reproduced.

Indeed, the OpenSSL devs ended up greatly improving how they do thread synchronization in general, because the issue was a combination of: a) using mutexes only, b) over time too many places got "get a reference to the cryptographic alg" calls that exacerbated all the problems with only using mutexes. So now OpenSSL has an RCU-like mechanism for thread synchronization that replaces mutexes for many read cases. That's _exactly_ the sort of large response program [to a systemic performance problem] that one would expect by an upstream that is well-funded and cares about performance.

So really, OpenSSL issue #20286 is demonstrative of all the opposite of what you say! It demonstrates that OpenSSL

  - is well-funded,
  - has skilled developers,
  - is responsive to their users,
  and
  - is willing to make massive
    changes to their codebase.

Show us how all of that is true of the others before you attack OpenSSL for having had a performance problem.

BTW, it was I who proposed switching to RCU for these synchronization problems, and I half-expected to be told that that's not portable. Instead and after convincing them that the problem was quite real they jumped wholeheartedly into developing an RCU-ish solution. How often does it happen to you that you point out a serious architectural problem to a popular upstream and then they take it seriously and solve it as quickly as possible? I'm sure it's a rare occurrence. It sure is for me.