Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Page Properties
label


Status

Status
colourYellow
titleIn progress
 

StakeholdersAleksandr Petrosyan Marin Versic
Outcome
Due date
OwnerSam H Smith


Background

CPU time and memory cost money. Faster software is better because it can do more with the same hardware. Adding new functionality is only useful so long as users are able to use it. Performance enables more use. It is therefore important that start focusing on improving iroha2 performance. We expect that a 50x performance increase is an achievable goal.

Problem

Informed decisions require metrics

It is not hard to walk towards a goal on the horizon. But if you are blindfolded, that task becomes impossible. You will drift off course without something to guide you. The same goes for the iroha2 core team. We have a good idea of where we would like to go. But we will not get there unless we have good guide, aka, good metrics. Specifically, real world measurements of a network's throughput, it's transactions per second.

Death by a thousand cuts

Currently the iroha2 codebase suffers from general slowness. Slowness that is very hard to pin down to any particular place in the codebase. There is no obvious bottle neck we can address. Instead we are faced with needing lots of small improvements in many places. The measurable performance difference due to any specific change is negligable. But combined they are what will get us to 50x. Even though we cannot use metrics to decide what change is good. They are still useful in making sure we have not made things worse. If you know that you haven't introduced a regression in performance you can refactor and simplify with confidence. This will allow us to do necessary optimization/simplification faster.

Solution

I will be regularly performing TPS benchmarks on a set of four machines. This will allow the iroha2 core team consistent insight into how code changes are affecting performance. I will establish a baseline TPS for the LTS release. That way we can make sure all our codebase simplications are improvements and not regressions. Some of this work can be handled by devops once the routine has been established.

...