到早上沒睡太多，之後努力繼續詳細每個環節測量和獲取歷史數據，考慮把udon做好。(昨天睡太多了)
大概異常高CPU開銷的avatar可以透過自己各種監控軟件獲取比對發現。
其中大概80%~90%由場景組織結構層次的API造成開銷，而觸發原因是約束(constraint)
即使不是很高的avatar也可能有30-50%這麼誇張高的佔比，比大概20-30%的動畫控制器來得高。(以看不見時的影響)
物理骨骼(簡稱PB)自從256組件限制後其實有持續優化限制一堆奇怪大量濫用物理骨骼avatar的問題，使得自身使用大量PB的avatar不會那麼卡，也不會那麼容易觸發週期性大量峰值CPU飆升的bug(部份情形下會變成常駐CPU開銷 吐血)
至少大概佔據10%背景開銷，而純骨骼開銷方面占比接近0%。
少數avatar因此在自身方面接近提升70%。
裡面的坑太多就不解釋了，有些數據發在vrchat ask公告裡，懶得轉了，直接結論。

這是複現結果，如果是大量骨骼組織的avatar缺乏動畫控制器關閉約束造成的結果(不良的管裡沒成功進入休息)，造成大量CPU浪費。
約5000個骨骼 120個約束即可造成此結果，有些avatar裡面佔據一半可能不到的CPU開銷，他們擁有1000-2000個骨骼100~400個約束，也僅僅只是造成了大約0.1~0.4ms(總共0.2ms~0.6ms每個avatar，已經很高了))，然而少數製作者設計不良，他們因此造成的開銷高達1ms以上甚至有可能到達3ms的極品。
如果我們能夠把約束全部消滅掉(然而對於avatar製作會麻煩些，期望有更好的處理方案)

同樣約8個avatar造成的CPU開銷對比，大約相當於820fps vs 47fps的巨大差距，不要覺得不可能，有些公開的avatar就是如此『差勁』。
自從PB問題被幹掉差不多後許多問題都較好追查了。
目前能找到造成串行化變成接近單核心的原因來自部份實質上只能單線程處裡的場景結構層次API。
這是優化前相當於1.4core的VRchat。

這是優化過後均衡許多約3core多的vrchat。

彼此之間在主線程上差距39.08%，而且是總負載的39.08%這可是相當於主線程佔比的55%，更別提還對整體CPU造成很多CPU週期開銷，以致於最終差距高達十幾倍fps(或著說avatar之間開銷差距十多倍)。
以上場景以沒有udon情況下測量結果為準。
我覺得VRC終極解決方案:取代掉約束，尤其是一些古怪的約束和大量骨骼層次結合使用，其次對於一些可能動畫控制器開銷高的場合，在script上提供兩種，一種視而不見可以徹底關閉，另一種則是全部運作，讓創作者自行根據需求選用，全力優化CPU開銷。