Pool lexers to reduce allocations and improve performance

[turbolent]

Description

@simonhf pointed out that execution is allocating a lot of memory, specifically emitting tokens in the token stream (append on a slice). Pre-allocating an array reduces the overhead of append.

I then also realized that the token stream itself is allocated and not used after parsing, so we can reduce allocations by introducing an object pool for lexers.

This significantly reduces amount of allocated memory and also increases performance as a side-effect.

Also, improve the benchmarking workflow:

• Enable memory statistics for all benchmarks
• Sort benchmarks by name. This makes it easier to find benchmarks in the output (e.g. see performance improvement -> check memory benchmark results)

---

• Targeted PR against master branch
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work
• Code follows the standards mentioned here
• Updated relevant documentation
• Re-reviewed Files changed in the Github PR explorer
• Added appropriate labels

[codecov]

Codecov Report

Merging #1610 (7d84b90) into master (f615bea) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1610      +/-   ##
==========================================
+ Coverage   74.73%   74.74%   +0.01%     
==========================================
  Files         288      288              
  Lines       55340    55356      +16     
==========================================
+ Hits        41357    41375      +18     
+ Misses      12489    12487       -2     
  Partials     1494     1494              

Flag	Coverage Δ
unittests	74.74% <100.00%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
runtime/parser2/lexer/lexer.go	96.15% <100.00%> (+0.20%)	⬆️
runtime/parser2/parser.go	90.33% <100.00%> (+0.08%)	⬆️
runtime/interpreter/storage.go	72.78% <0.00%> (+1.36%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f615bea...7d84b90. Read the comment docs.

[github-actions]

Cadence Benchstat comparison

This branch with compared with the base branch onflow:master commit f615bea
The command for i in {1..N}; do go test ./... -run=XXX -bench=. -benchmem -shuffle=on; done was used.
Bench tests were run a total of 7 times on each branch.

Results

	old.txt	new.txt
	time/op		delta
CheckContractInterfaceFungibleTokenConformance-2	164µs ± 7%	157µs ± 3%	~	(p=0.101 n=7+6)
ContractInterfaceFungibleToken-2	45.1µs ± 9%	44.8µs ±14%	~	(p=0.710 n=7+7)
InterpretRecursionFib-2	2.90ms ± 9%	2.75ms ± 4%	~	(p=0.234 n=7+6)
NewInterpreter/new_interpreter-2	1.26µs ± 9%	1.25µs ± 8%	~	(p=0.902 n=7+7)
NewInterpreter/new_sub-interpreter-2	2.53µs ± 9%	2.39µs ± 8%	~	(p=0.128 n=7+7)
ParseArray-2	14.4ms ± 9%	8.0ms ± 5%	−44.59%	(p=0.001 n=7+7)
ParseDeploy/byte_array-2	22.4ms ±10%	11.7ms ± 3%	−47.66%	(p=0.001 n=7+7)
ParseDeploy/decode_hex-2	1.32ms ± 7%	1.28ms ± 6%	~	(p=0.318 n=7+7)
ParseFungibleToken-2	211µs ± 3%	152µs ± 4%	−27.76%	(p=0.001 n=6+7)
ParseInfix-2	9.32µs ±10%	6.97µs ± 8%	−25.17%	(p=0.001 n=7+7)
QualifiedIdentifierCreation/One_level-2	3.07ns ± 8%	2.96ns ± 6%	~	(p=0.259 n=7+7)
QualifiedIdentifierCreation/Three_levels-2	155ns ± 8%	152ns ± 8%	~	(p=0.456 n=7+7)
RuntimeFungibleTokenTransfer-2	1.51ms ±26%	1.60ms ± 8%	~	(p=0.731 n=7+6)
RuntimeResourceDictionaryValues-2	7.56ms ±12%	7.39ms ± 6%	~	(p=0.620 n=7+7)
Transfer-2	94.3ns ± 9%	95.1ns ± 8%	~	(p=0.535 n=7+7)
	alloc/op		delta
CheckContractInterfaceFungibleTokenConformance-2	66.3kB ± 0%	66.3kB ± 0%	~	(p=1.000 n=7+7)
ContractInterfaceFungibleToken-2	26.7kB ± 0%	26.7kB ± 0%	+0.00%	(p=0.033 n=6+7)
InterpretRecursionFib-2	1.14MB ± 0%	1.14MB ± 0%	~	(p=1.000 n=7+7)
NewInterpreter/new_interpreter-2	848B ± 0%	848B ± 0%	~	(all equal)
NewInterpreter/new_sub-interpreter-2	1.34kB ± 0%	1.34kB ± 0%	~	(all equal)
ParseArray-2	13.5MB ± 0%	3.0MB ± 0%	−77.91%	(p=0.001 n=7+6)
ParseDeploy/byte_array-2	21.0MB ± 0%	4.3MB ± 2%	−79.56%	(p=0.001 n=7+7)
ParseDeploy/decode_hex-2	218kB ± 0%	213kB ± 0%	−2.08%	(p=0.001 n=7+7)
ParseFungibleToken-2	199kB ± 0%	36kB ± 0%	−81.77%	(p=0.001 n=7+7)
ParseInfix-2	6.76kB ± 0%	2.10kB ± 0%	−68.87%	(p=0.001 n=7+7)
QualifiedIdentifierCreation/One_level-2	0.00B	0.00B	~	(all equal)
QualifiedIdentifierCreation/Three_levels-2	64.0B ± 0%	64.0B ± 0%	~	(all equal)
RuntimeFungibleTokenTransfer-2	273kB ± 0%	234kB ± 0%	−14.27%	(p=0.001 n=7+7)
RuntimeResourceDictionaryValues-2	2.25MB ± 0%	2.24MB ± 0%	−0.53%	(p=0.001 n=7+7)
Transfer-2	48.0B ± 0%	48.0B ± 0%	~	(all equal)
	allocs/op		delta
CheckContractInterfaceFungibleTokenConformance-2	1.07k ± 0%	1.07k ± 0%	~	(all equal)
ContractInterfaceFungibleToken-2	460 ± 0%	460 ± 0%	~	(all equal)
InterpretRecursionFib-2	23.8k ± 0%	23.8k ± 0%	~	(all equal)
NewInterpreter/new_interpreter-2	13.0 ± 0%	13.0 ± 0%	~	(all equal)
NewInterpreter/new_sub-interpreter-2	40.0 ± 0%	40.0 ± 0%	~	(all equal)
ParseArray-2	70.0k ± 0%	70.0k ± 0%	−0.03%	(p=0.001 n=7+6)
ParseDeploy/byte_array-2	105k ± 0%	105k ± 0%	−0.02%	(p=0.000 n=7+6)
ParseDeploy/decode_hex-2	86.0 ± 0%	79.0 ± 0%	−8.14%	(p=0.001 n=7+7)
ParseFungibleToken-2	1.07k ± 0%	1.06k ± 0%	−1.12%	(p=0.001 n=7+7)
ParseInfix-2	73.0 ± 0%	66.0 ± 0%	−9.59%	(p=0.001 n=7+7)
QualifiedIdentifierCreation/One_level-2	0.00	0.00	~	(all equal)
QualifiedIdentifierCreation/Three_levels-2	2.00 ± 0%	2.00 ± 0%	~	(all equal)
RuntimeFungibleTokenTransfer-2	4.58k ± 0%	4.57k ± 0%	−0.22%	(p=0.001 n=7+7)
RuntimeResourceDictionaryValues-2	37.6k ± 0%	37.6k ± 0%	−0.03%	(p=0.000 n=7+5)
Transfer-2	1.00 ± 0%	1.00 ± 0%	~	(all equal)

[SupunS]

Nice optimization! 👌 Just a one question

[janezpodhostnik]

LGTM.