On Wed, May 18, 2022 at 12:50:48PM +0300, Henrik K wrote: > On Wed, May 18, 2022 at 12:40:42PM +0300, Henrik K wrote: > > On Wed, May 18, 2022 at 11:29:40AM +0200, Michael Storz wrote: > > > > > > Yes, it is really simple and I can understand it now :-), thanks. > > > However, I > > > would still prefer to be able to use the optimized version of MIME::Base32 > > > if this module is installed. For us the installation is no problem, it > > > would > > > just be a statement in our puppet class for SpamAssassin to install it on > > > all servers with SpamAssassin. > > > > > > Ah, I just saw that we still need to use the SH.pm plugin, since HashBL.pm > > > doesn't support attachment hashes. That's where the performance of > > > encode_base32 makes the biggest difference. Good thing I rewrote the whole > > > SH.pm plugin to support caching. > > > > But all the calls of encode_base32 in SH.pm only encode results of sha256() > > call? The performance should make no different as it's tiny string. > > > > I'd rather spend my time actually implementing the attachment hashes. :-) > > Actually now that I did a quick benchmark of million rounds, my lousy code > is _faster_ than MIME::Base32. 10 seconds vs 17 seconds. > > I think mine might use more memory as it's handling the bits as a string.. > but it's faster. :-D
And before you question anything. I of course did a script that generates random strings of different sizes and run million loops to compare mine and MIME::Base32 output. There were no differences. I didn't bother to do separate benchmark at that time.
