MessagePack-CSharp / MessagePack-CSharp/MessagePack-CSharp
[Performance][Optimization] Method inline question
- Dominant language
- C#
- Stars
- 6.8k
- Forks
- 775
- Avg merge
- 3h 26m
- Merged PRs (30d)
- 6
Description
Dear gents, I'm trying to squeeze every ns in de/serialization process - we are operating on 100-GBs scale.
My attention was caught on how primitives are being read/inflated, saying `MessagePackReader.Integers.cs`
The op (internally) is to read bytes from span (aka `SequenceReader`) & increment position.
While it (`MessagePackReader`) is beef-ed with multiple method calls:
- `ReadInt32`
- `ThrowInsufficientBufferUnless`
- `TryReadBigEndian`
- `TryRead`
Keeping in mind absolute cost of method call being `cheap/non-negative` there could be a vision **the flow is fine**.
However, if we scale/compare to logical operation reader has to do = read from array in memory VS ((push a few args into reg + call method)*3) = costly.
A few methods are marked as subject for inline `MethodImpl(MethodImplOptions.AggressiveInlining)]`.
It seem like a good idea to decorate more methods with `inline` option on the surface (considering they operate on same args).
The question is - were there any specific reasons why only a few inlined, or it is just codebase lifetime development (as-is)?
Cheers,
Nik
Contributor guide
Research direction
Start with MessagePackReader.Integers.cs and inspect the implementations of ReadInt32, ThrowInsufficientBufferUnless, TryReadBigEndian, and TryRead. Determine whether additional aggressive inlining is justified for the deserialization path and document the measured or technically supported rationale, with any resulting scope clearly identified.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- performance
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100