> Very interesting results. Did you run this on a build from /trunk/ -
> ie with OpenSSL 3.1?
Yes, these results were from trunk with OpenSSL 3.1. However, I believe that
they should be similar with OpenSSL 1.1.x as well.
> The reason for the no-asm option was that the asm code often (it felt like
> every other release) was broken. Either with the asm that comes with VS,
> or later with MASM as well: When they switched to requiring MASM I thought
> the build problems were solved, but the second version after the switch
> failed again.
>
> So I had enough and used the no-asm switch.
Let me try to summarize and list a few more reasons on why I think that
switching to the default OpenSSL build could be beneficial for the project:
1. The improvement comes from using AES-NI instructions for HTTPS.
So this should reduce the CPU usage for all network operations. Perhaps, it
could be especially visible on low-tier hardware.
2. Spending less CPU on common operations means more laptop battery time
and more CPU available for other tasks, in all setups.
For example, here are a couple of additional benchmarks performed over
typical 1Gb LAN that illustrate the overall CPU time reduction:
Null-export of Subversion root dir, 1Gb LAN:
CPU time: 130 sec 🠒 8 sec (16x less CPU used)
Total time: 175 sec 🠒 175 sec
Avg CPU load: 74% 🠒 4%
Null-export of .iso file, 1Gb LAN:
CPU time: 13 sec 🠒 1 sec (13x less CPU used)
Total time: 63 sec 🠒 63 sec
Avg CPU load: 20% 🠒 2%
3. Building OpenSSL with assembler support is the current default.
Multiple known projects such as Node.js seem to use and regularly test this
configuration on different platforms and provide additional test coverage.
Compared to that, I think that the `no-asm` build falls into the group of
non-standard configurations (maybe even not intended for production use),
and therefore it could be far less tested in practice.
4. Perhaps you are right about the real setups/throughput, but SVN is good
at handling large files and so there might be users that have multi-terabyte
repositories containing assets and other large binaries.
If these users work through 10GbE (which maybe isn't too uncommon
nowadays), they'll get a significant speedup for their regular operations.
Best Regards,
Denis Kovalchuk
--
You received this message because you are subscribed to the Google Groups
"TortoiseSVN-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tortoisesvn-dev/c7590b2a-4c54-4111-8b69-4acd00910459n%40googlegroups.com.
