Declarative RLP Encoding/Decoding

[emlautarom1]

Changes

• Introduce an alternative approach to RLP encoding and decoding, based on a declarative API with support for code generation through Source Generators

Types of changes

What types of changes does your code introduce?

• Bugfix (a non-breaking change that fixes an issue)
• New feature (a non-breaking change that adds functionality)
• Breaking change (a change that causes existing functionality not to work as expected)
• Optimization
• Refactoring
• Documentation update
• Build-related changes
• Other: Description

Testing

Requires testing

• Yes
• No

If yes, did you write tests?

• Yes
• No

Notes on testing

The core library has 100% test coverage. Source generated code might not be fully covered.

Documentation

Requires documentation update

• Yes
• No

Requires explanation in Release Notes

• Yes
• No

Remarks

When we started working on refactoring our TxDecoder one thing that came up was how unergonomic is to work with our current RLP API. We even have some comments on the code itself mentioning these difficulties, for example:

nethermind/src/Nethermind/Nethermind.Serialization.Rlp/Eip2930/AccessListDecoder.cs

Lines 17 to 23 in b81070d

	/// <summary>
	/// We pay a high code quality tax for the performance optimization on RLP.
	/// Adding more RLP decoders is costly (time wise) but the path taken saves a lot of allocations and GC.
	/// Shall we consider code generation for this? We could potentially generate IL from attributes for each
	/// RLP serializable item and keep it as a compiled call available at runtime.
	/// It would be slightly slower but still much faster than what we would get from using dynamic serializers.
	/// </summary>

nethermind/src/Nethermind/Nethermind.Serialization.Rlp/Eip2930/AccessListDecoder.cs

Lines 76 to 81 in b81070d

	/// <summary>
	/// We pay a big copy-paste tax to maintain ValueDecoders but we believe that the amount of allocations saved
	/// make it worth it. To be reviewed periodically.
	/// Question to Lukasz here -> would it be fine to always use ValueDecoderContext only?
	/// I believe it cannot be done for the network items decoding and is only relevant for the DB loads.
	/// </summary>

This PR introduces a new RLP API based on #7334 (comment) with several improvements:

• Describe the structure of a record and get encoding and decoding for free. No code duplication required.
• Records can be described using other records. Supports conditional, exceptions, function calls, etc.
• Decoding and encoding are extensible through classes that can be defined anywhere, plus some extension methods.
• Minimal core library with 100% code coverage.
• Supports backtracking.
• All function calls are known ahead of time (no virtual or override). Interfaces are only used to enforce implementations.
• Despite the extensive usage of lambdas, no closures are required (all lambdas are static). You can still use them if you want to, but overloads are provided to avoid them.
• Automatically generate the required code through Source Generators.

[emlautarom1]

TrimStart does not seem to be heavily optimized. There might be something better that we can use, specially considering that we're removing leading zeros.

[LukaszRozmej]

Looks like .net doesn't use SIMD for it!
We could write Vector based way to find start index.
@benaadams

[Scooletz]

Replacing Marshal.SizeOf<T>() with sizeof(T) and some unsafe annotations gives quite the boost at no cost:

| Method  | Mean     | Error   | StdDev  | Ratio | RatioSD |
|-------- |---------:|--------:|--------:|------:|--------:|
| Current | 359.8 us | 5.03 us | 4.70 us |  1.00 |    0.02 |
| Fluent  | 626.2 us | 2.90 us | 2.42 us |  1.74 |    0.02 |

2x slower. Quite a lot. Can you add the ASM diagnoser and memory diagnoser? Would be nice to compare it more.

[emlautarom1]

After running some benchmarks I found that UInt256 was getting boxed due to the usage of interface default bodies. Fixing that issue improves performance and drastically reduces memory allocation (added [MemoryDiagnoser] as requested by @Scooletz):

| Method  | Mean     | Error   | StdDev  | Ratio | Gen0     | Gen1     | Gen2     | Allocated  | Alloc Ratio |
|-------- |---------:|--------:|--------:|------:|---------:|---------:|---------:|-----------:|------------:|
| Current | 359.5 us | 0.98 us | 0.86 us |  1.00 | 166.5039 | 166.5039 | 166.5039 | 1033.87 KB |        1.00 |
| Fluent  | 530.1 us | 4.67 us | 4.14 us |  1.47 |  51.7578 |  51.7578 |  51.7578 |   617.5 KB |        0.60 |

[Scooletz]

This line is responsible for all the allocations as it allocates a new array underneath

nethermind/src/Nethermind/Nethermind.Serialization.Rlp/RlpStream.cs

Line 44 in 4e44559

_data = new byte[length];

Is this the case that we want to benchmark or rather it should be a reused RlpStream here?

[emlautarom1]

To be comparable with the FluentRlp approach we should allocate a new buffer. Since both will allocate the same buffer size then it should not matter.

[Scooletz]

I see. If they allocate the same buffer, what makes the current allocate over 400kb more then? Is it the different return type Nethermind.Core.Eip2930.AccessList vs AccessList in the new one or something else? With 400kb more the current will be greatly penalized.

[emlautarom1]

Interestingly they're not allocating the same buffer size: the fluent approach uses a buffer of 170850 bytes while the current one uses 172845. That does not account for the 400kb you mention though. Rider's profiler is not giving me anything useful so I'm kind of stuck now.

Maybe we should add other objects (ex. LogEntry, BlockInfo, etc.) to get more accurate benchmarks.

[LukaszRozmej]

you can use NettyRlpStream that uses arena memory

[LukaszRozmej]

ArrayPool?

[emlautarom1]

By default I think we should go with a plain array to match the ArrayBufferWriter behavior. At the end of the day, the RLP static class is like a "safe default" API.

If we want more control over the buffers we use we can write a custom IBufferWriter as you suggested earlier while using RlpReader and RlpWriter directly.