perf: Optimize NetworkList indexer setter performance

[harayuu9]

This PR adds an equality check to the NetworkList<T> indexer setter, aligning its behavior with NetworkVariable<T>.Value. Since NetworkList<T> already constrains T to IEquatable<T>, this change is both safe and broadly applicable. It avoids redundant assignments when the new value is equal to the current value, which improves runtime efficiency and avoids unnecessary event dispatch and network synchronization.

Changelog

com.unity.netcode.gameobjects

• Changed: Optimized NetworkList<T> indexer setter to skip operations when the new value equals the existing value, improving performance by avoiding unnecessary list events and network synchronization.

Testing and Documentation

• No documentation changes or additions were necessary.

Backport

Not applicable.

[EmandM]

Thanks again for the submission! This seems like a fantastic and needed optimization. I'll pull this over internally.

In case you didn't know, it's now possible to use Collections inside of NetworkVariables. So you can use NetworkVariable<CollectionType> and NGO will use network optimized deltas for the network variable updates (docs).

We're super interested if you have any feedback on the usage of NetworkList<T> vs NetworkVariable<List<T>>.

[harayuu9]

@EmandM
I’ve looked into that, thank you. In my specific use case, I’m working with fairly large 2D maps—256x256 or even larger—so the data size is significant. Additionally, updates occur quite frequently, roughly once every 5 frames. Because of this, performance took a substantial hit when using NetworkVariable due to the cost of diffing such large structures.

Another important factor is that NetworkListEvent provides a much more convenient and flexible event-driven model. It functions similarly to ObservableCollection in that it allows me to handle changes in a fine-grained way. In my scenario, I can efficiently create, delete, or modify objects only on the specific tiles that have changed.

[EmandM]

Cheers for the feedback! It's great to have performance improvements that are based on real-life use-cases. We'll land this fix over in #3587