MessagePack-CSharp / MessagePack-CSharp/MessagePack-CSharp

[Performance][Optimization] Method inline question

Đang mở
#1,807 5 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Ngôn ngữ chính
C#
Star
6.8k
Fork
775
Merge trung bình
3 giờ 26 phút
Pull request đã merge (30 ngày)
6

Mô tả

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

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Hướng nghiên cứu

Bắt đầu với MessagePackReader.Integers.cs và kiểm tra các triển khai của ReadInt32, ThrowInsufficientBufferUnless, TryReadBigEndian và TryRead. Xác định liệu có cơ sở để thực hiện aggressive inlining bổ sung cho đường dẫn giải tuần tự hay không, đồng thời ghi lại cơ sở được đo lường hoặc được hỗ trợ về mặt kỹ thuật, với mọi phạm vi phát sinh được xác định rõ ràng.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Đánh giá

Công nghệ
csharp
Lĩnh vực
performance
Loại issue
Tái cấu trúc
Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức độ hoạt động
Đình trệ
Độ rõ ràng
Cần làm rõ
Mức phù hợp với người mới
25/100

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.