Unity的update()和Event事件系统性能比较
注意,从国外文章看到UnityEvent系统比c#自带的Event系统性能要差，但是好处是可以在编译器可视化。其结果如下图：
英语原文：
C# events beat UnityEvent for each number of arguments. The gap widens as more args are dispatched to the listeners. In the best case, UnityEvent takes 2.25x longer than C# events but in the worst case it takes almost 40x longer!
In conclusion, UnityEvent creates less garbage than C# events if you add more than two listeners to it, but creates more garbage otherwise. It creates garbage when dispatched (Update: the first time) where C# events do not. And it’s at least twice as slow as C# events. There doesn’t seem to be a compelling case to use it, at least by these metrics.
然后是Update()和Event的性能比较，原文是
For anyone interested in this and stumbling upon it later, I have run three tests and the TLDR is: Unsurprisingly, do not use Update on too many game objects active in a scene at the same time, even on low frequency methods like this.
My test script simply spawns X amount of GameObjects based on a prefab that has either a
a) script with the computation done in its Update method, （Update方程，每帧检查）
b) a script to subscribe to an event published by a manager behaviour, or （事件系统，触发了才会运行）
c) a script that adds itself to a list to be later iterated through by the manager behaviour (based on /u/Xeros778 suggestion). （触发了遍历的系统，具体写法是：Maybe option three, by having the manager class directly call a public function on each gameobject. This would require no event calls, but would require the manner class to store a list of all objects.）
In all cases, the test method is called after 2 seconds have passed, with corresponding time checks done in the relevant Update method. The test method itself generates 10,000 random numbers from a base random - nothing useful or very computationally difficult. But the test method, ultimately, did not matter, as Update being present on Monobehaviours is the biggest drain.
For 20,000 game objects that run the test method in a 2 second interval,
a) 5.24ms CPU/frame, total memory 6.97 GB
b) 0.17ms CPU/frame, total memory 7.49 GB
c) 0.14ms CPU/frame, total memory 6.02 GB
总结，c胜者，b更占内存，a非常消耗cpu
For 100,000 game objects, also running a test method in a 2 second interval:
a) 26.62ms CPU/frame, total memory 11.08 GB
b) 0.17ms CPU/frame, total memory 10.34 GB
c) 0.15ms CPU/frame, total memory 9.59 GB
同上，c是显著胜者
So, the List option does somewhat better than Events in this test at least, also in regards to memory usage. Update is magnitudes worse compared to either approach.
Even without any computations done in Update, the mere presence of the method call is the culprit. I was not aware of the severity of this. 100k game objects active is of course a huge number, but still.
Depending on the weight of what actually needs to be calculated each interval, using a job system for the actual computations might indeed be worthwhile.
