Thread by @fuserleer

I've been v.quiet lately as I'm laser focused on #cassie cleanup, improvements, testing etc but it's going well.

Starting to get some tangible results that are interesting to the #crypto crowd so thought I'd share in a thread ⚠️

Some background first.

The #cassie code base before starting this work was a real bloody mess!

My focus was to find a solutoon/implementation that worked, not to write clean, pretty, fast code.

Hacking around with ideas & progressive theory produces terrible code.

So much so that even though I'd proven out the theory to mine (and others) satisfaction, running long tests was prone to crashing because some no longer used code was being called somewhere deep in #cassie belly under some edge condition. V. Frustrating!

Most of the work I've been doing hasn't been in the domain of optimization, even though it usually does produce performance improvements.

Namely things like improving exception handling, argument checks where they were missing, better use of threads, pipelining improvements...

... On producers / consumers, improvements to concurrency handling using better suited primitives or different locking styles, or even removing redundant locks where possible, refactoring the many huge hunks of monolithic code and of course...

Deleting code that is no longer needed but frequently still be called for all manner of stuff!

Deleted code has zero bugs, it's my favorite!

Anyway still a ways to go but moving very nicely in the right direction.

Before I started I did a baseline soak test...

Small network, to keep things simple, 8 shard groups, 4 validators in each with a spec of 4 core 8 gb + ssd injecting 10M tweets as fast as possible with 20% failure rate. Failures are expensive!

At each validator #tps averaged 170, finality 38s, bandwidth use ~8MB/s

Same test but today, #tps is up to 300 average, finality ~31s, bandwidth ~4MB/s

Oh and it crashes MUCH less haha 😎👍