Tomaž Jerman

Benchmarks for the reworked version: ``` goos: darwin goarch: arm64 pkg: github.com/cortezaproject/corteza/server/pkg/rbac Benchmark_AccessCheck_role100_rule1000-12 101308 11020 ns/op 5120 B/op 23 allocs/op Benchmark_AccessCheck_role100_rule10000-12 106794 10392 ns/op 5119 B/op 23 allocs/op Benchmark_AccessCheck_role100_rule100000-12 106137...

Comparing the numbers Number for averages ``` time 3031 times better memory 1.85 times better allocs 53.64 times better ``` Numbers per benchmark ``` Benchmark_AccessCheck_role100_rule1000-12 time 26437/11020=2.39 times better memory...

### Peek into the change Instead of simple hash maps, we introduce a variation of [a trie](https://en.wikipedia.org/wiki/Trie). We split up the RBAC rule in chunks (separated by `/`) and use...

# Benchmarks & Analysis ## Simple workflow with sequence iterator The workflow is a simple iterator with 10k iterations: ``` goos: darwin goarch: arm64 pkg: github.com/cortezaproject/corteza/server/tests/workflows Benchmark_bench_exec_base-12 1 4501291542 ns/op...

## Removing the state change handler Removing the state change handler to see what the best case scenario would be: ``` goos: darwin goarch: arm64 pkg: github.com/cortezaproject/corteza/server/tests/workflows Benchmark_bench_exec_base-12 1 1001210917...

## Processing expressions Benchmarking `pkg/expr#PathSplit` we see: ``` goos: darwin goarch: arm64 pkg: github.com/cortezaproject/corteza/server/pkg/expr BenchmarkSplit-12 1948309 613.0 ns/op 4370 B/op 7 allocs/op ``` Introducing some aux structure to better traverse...

Updating `expr.Assign` with the reworked structure, we go from ``` goos: darwin goarch: arm64 pkg: github.com/cortezaproject/corteza/server/pkg/expr BenchmarkAssign-12 1811497 662.7 ns/op 4368 B/op 6 allocs/op ``` to ``` goos: darwin goarch:...

## Simple workflow without state change handler and reworked expressions Same iterator but the state change handler is turned off and expressions tweaked Original numbers (without state change handler): ```...

## Trying to figure out why it's taking so long Taking a peek at the CPU profile, we see this:  This hints some locking/blocking is going on. My guess...

Grabbing an execution trace we see something interesting: * There are (seemingly) random gaps inside the trace * There are gaps between each benchmark iteration (I forgot to grab a...