improve locking performance by using a RWMutex and avoiding defer when possible

[aaron2]

No description provided.

[mihasya]

For a PR like this, it would be useful to provide some benchmark results - was this a pressing issue that came up in profiling? If not, I'd rather just stick to the simplicity of a mutex.

[aaron2]

sorry I dont have any benchmarks but it was an issue that came up in profiling. we run this code in production at a large scale in a latency sensitive application. I have a few more PRs to contribute too if this project is going to be active again.

[mihasya]

It ebbs and flows :) Things are calming down a little on the work and travel front, so I found myself with a few free minutes and was reminded by another PR to take a look at the backlog.

Things that would really help me merge this PR:

• a rebase (sorry, I went on a bit of a spree last night 😆 )
• a few simple tests that exercise the concurrency. I've got another PR I'm about to merge ( more go versions; add race detector to tests #218 ) that adds -race to the test command, so if we simply add tests that do nothing but execute some Register commands etc in goroutines, that should be enough for the race detector to do its thing. Yes, these are things that should have been there when the code was originally written, but, here we are :)

If you don't have time to add the tests, let me know and I'll try to add some on an upcoming train trip. Also very curious what else you have up your sleeve.

Thanks for the PR and sorry for such a delayed response. I'm trying to do better.

[mihasya]

Closing in favor of #226 in the hopes that benchmarks and concurrency tests can be contributed there. #232 has confirmed that my conservatism on these sorts of PRs is warranted.