3 ms·
The small performance degradation could be a good thing - it may be a result of the use of explicit_bzero to clear sensitive data structures (instead of memset
by stephen_g 12y ago
The small performance degradation could be a good thing - it may be a result of the use of explicit_bzero to clear sensitive data structures (instead of memset which was used previously) before freeing.
It could mean that a fair bit of that important cleaning was being optimised out before with OpenSSL.
- axaxs 12y agoPossibly, but it could also be much faster with all the cruft gone. Dynamic linking has a small overhead, so would love to see an apples to apples comparison.
- stephen_g 12y agoDefinitely to some extent, but I think the cruft would have a much smaller effect. Much of it was dead code - commented out, whole files not actually compiled, code ifdefed out, or bits of code only compiled on platforms that nobody has used this decade etc. It was making maintainability a nightmare and making it a lot harder to find bugs, but I don't think it would have had a huge performance impact.
- AlyssaRowan 12y agoWe shouldn't really have to wonder about this kind of thing. explicit_bzero() for glibc, please! It's probably dynamic/static noise. I don't think zeroisation would have an overhead as big as 4%. But then, I haven't measured: it's easy enough to do an A-B test with a castrated version and see?
- castorio 12y agoyou might be right: i did a new test with nginx+libressl static and the results are very similar: https://www.mare-system.de/static/bimages/nginx-libressl/perftest.png https://www.mare-system.de/static/bimages/nginx-libressl/per...