Unity-Technologies / Unity-Technologies/com.unity.netcode.gameobjects

Named Messages: Don't allocate a byte array whenever you send a message

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

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

type:feature
Ngôn ngữ chính
C#
Star
2.3k
Fork
461
Merge trung bình
3 ngày 16 giờ
Pull request đã merge (30 ngày)
20

Mô tả

Is your feature request related to a problem? Please describe.
Named Messages are a great way to send custom messages that are not tied to a specific game object and/or are more dynamic than standard RPC calls. However, the only way to send these messages (via CustomMessagingManager.SendNamedMessage) is by providing a string which gets then hashed using XXHash.Hash32 or XXHash.Hash64 which then calls Encoding.UTF8.GetBytes(text). This function always allocates a new byte array, containing the string. As far as I can see, there is no other possible way to send a named message.

Describe the solution you'd like
I see two possible solutions:

  • Don't use Encoding.UTF8.GetBytes(text) and instead use one of the overloads where you can specify an existing byte[] or Span. This would allow the use of a pre-alloced buffer (e.g. from a temp alloced NativeArray or an array pool).
  • Add a function overload where I can provide the hash myself (and provide a way to obtain this hash). This would work similar to e.g. Animator.StringToHash or Shader.PropertyToID. However, the HashSize can be 4 bytes or 8 bytes (depending on NetworkManager.NetworkConfig.RpcHashSize) and can even change during the runtime (at least, CustomMessageManager supports this case). Therefore it might be a bit confusing to the user which hash (with which data type) they have to use in this case - unless the GetHash function returns a struct which contains both hashes...which might be a bit weird as well.

Describe alternatives you've considered

  • I can use unnamed messages and just re-implement the logic from named messages, using the solution described above.

Additional context

Example GC Alloc from the profiler:

Size: 41

Call Stack:
mscorlib.dll!System.Text::Encoding.GetBytes()
Unity.Netcode.Runtime.dll!Unity.Netcode::XXHash.Hash32()	./Library/PackageCache/com.unity.netcode.gameobjects@1.5.2/Runtime/Hashing/XXHash.cs:218
Unity.Netcode.Runtime.dll!Unity.Netcode::CustomMessagingManager.SendNamedMessage()	./Library/PackageCache/com.unity.netcode.gameobjects@1.5.2/Runtime/Messaging/CustomMessageManager.cs:296
Unity.Netcode.Runtime.dll!Unity.Netcode::CustomMessagingManager.SendNamedMessageToAll()	./Library/PackageCache/com.unity.netcode.gameobjects@1.5.2/Runtime/Messaging/CustomMessageManager.cs:236

I wouldn't say this is a huge problem (though it depends on how many messages are being sent and how long their name is), and unnamed messages are an easy workaround. However, most of this package seems to focus on allocating as little as possible, and I think that fixing this problem here shouldn't be too hard (otherwise just ignore this issue).

Thanks for your work on this amazing package, I really enjoy using it! I can also provide a PR with a fix mentioned above if you would like me to, I just didn't want to submit something unwanted.

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 bằng cách đọc Runtime/Hashing/XXHash.cs và Runtime/Messaging/CustomMessageManager.cs, đặc biệt là đường dẫn gọi SendNamedMessage và phần cấp phát được ghi nhận tại các dòng đã báo cáo. Dùng profiler để tái hiện việc cấp phát khi gửi message có tên, sau đó xác định cách tránh việc này trong khi vẫn giữ nguyên hành vi hash 32-bit và 64-bit khi kích thước hash được cấu hình thay đổi. Công việc được xem là hoàn tất khi các lần gửi có tên không còn cấp phát mảng byte của tên và hành vi hiện có vẫn được các bài kiểm thử khả dụng bao phủ.

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, unity
Lĩnh vực
networking, performance
Loại issue
Tính năng
Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức độ hoạt động
Đình trệ
Độ rõ ràng
Khá rõ ràng
Mức phù hợp với người mới
38/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.