commit 6eba9868459ea23a9409700c2b95dd6007023323
author Asim Shankar <ashankar@google.com> Thu Sep 03 01:07:14 2015 -0400
committer Asim Shankar <ashankar@google.com> Thu Sep 03 01:07:14 2015 -0400
tree 6c2ba5b4e08fa324cfe23ba11121b6bc0393929c
parent cbeae82ab0dd1dc2622511966a73583ecb5a51e3

security: Avoid unnecessarily public key marshaling/unmarshaling.

Most places where "recognition" of a root public key is to be tested
(via BlessingRoots.Recognized), the marshaled form of the key is
available. However, given the BlessingRoots API prior to this commit,
the code ended up unmarshaling the bytes into an object and then the
BlessingRoots implementation would marshal it back into a string
in order to lookup a cache key. This was simply a waste of time.

The BlessingRoots API (in particular the Add and Recognized methods) are
likely to not be directly used outside the Vanadium runtime
implementation. By changing their signature to take serialized keys
instead of objects, we see a significant speedup (3-9x) in
RemoteBlessingNames, which will be used by developers more frequently.

go test v.io/v23/security -bench RemoteBlessingNames
(values are in ns/op):
                              BEFORE AFTER SPEEDUP
BenchmarkRemoteBlessingNames  75746   8451 9x
BenchmarkRemoteBlessingNames  24741   8081 3x [-tags noopenssl]

It is curious that the OpenSSL implementation is still a bit slower
than a pure Go implementation in this benchmark. I'm looking into that
(and currently creation of an OpenSSL-based public key does involved an
extra Marshaling/Unmarshaling).

MultiPart: 2/3
Change-Id: I2c9776175c51b9fc56d093567d71a8341125f358