Short version: Not really. Long version: BounchBench compared symmetric ciphers in different byte sizes in a loop. To simulate dB style usage, it defaults to "small size, many writes" (eg: 200 writes, 10 bytes each) and each write is encrypted individually. To facilitate comparing different ciphers, everything is against a standardized against a higher order interface (than IBlockCipher or IAeadBlockCipher) that has stuff like byte[] Encrypt(...) and byte[] Decrypt(...) meaning there is a small wrapper layer around them all. All ciphers are instantiated inside the test loop and for AES-GCM this meant incurring a heavy initialization penalty inside the loop, so what Peter did is 1) moved some portion of the AES-GCM init code into the class' constructor ( this portion: GcmBlockCipher cipher = new GcmBlockCipher(new AesFastEngine(), new Tables8kGcmMultiplier())) 2) Tweaked the test by instantiating the cipher objects outside the test loop (i.e. the new part) and keeping only the cipher object initialization (at Init(Key)) inside the loop with another check *inside *Init to skip key init if it's the same.
#2 affects all benchmarks and after the above AES-GCM is far more competitive as,say, AES-CBC. Yeah, you could argue we're cheating the benchmark because the other ciphers can run full steam without that sort of "tuning" or demanding object reuse. At the same time it's a good coding technique anyway, so I pulled that change into BouncyBench. If I had more time, I would have opened profiled it better and seen if deeper/core optimizations are possible and compared to OpenSSL's AES-GCM code. Sadly, I don't have that time with real world commitments ... Regards, Sid
