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

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

Aperta
#2,779 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

type:feature
Lingua principale
C#
Stelle
2.3k
Fork
461
Merge medio
3g 16h
PR unite (30g)
20

Descrizione

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.

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Direzione di ricerca

Inizia leggendo Runtime/Hashing/XXHash.cs e Runtime/Messaging/CustomMessageManager.cs, in particolare il percorso di chiamata di SendNamedMessage e l’allocazione indicata alle righe segnalate. Riproduci con il profiler l’allocazione dei messaggi denominati, quindi determina come evitarla preservando sia il comportamento dell’hash a 32 bit sia quello a 64 bit quando cambia la dimensione dell’hash configurata. Il lavoro è completato quando gli invii denominati non allocano più l’array di byte del nome e il comportamento esistente continua a essere coperto dai test disponibili.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
csharp, unity
Ambito
networking, performance
Tipo di issue
Funzionalità
Difficoltà
4/5
Tempo stimato
3-5 giorni
Stato di attività
Ferma
Chiarezza
Abbastanza chiara
Idoneità per principianti
38/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.