- Unity द्वारा इस्तेमाल किया जाने वाला Mono runtime नवीनतम .NET की तुलना में काफ़ी धीमी execution speed दिखाता है, और एक ही C# कोड में अधिकतम 15 गुना तक का अंतर देखा गया है
- वास्तविक game code में Mono-आधारित Unity execution 100 सेकंड और उसी कोड की .NET execution 38 सेकंड मापी गई, जिससे debugging और testing efficiency पर बड़ा असर पड़ता है
- Release mode में भी Mono 30 सेकंड और .NET 12 सेकंड पर रहा, यानी optimized environment में भी 2.5 गुना से अधिक performance gap बना रहता है
- इसकी वजह Mono का अप्रभावी JIT compilation और inlining failure, ज़रूरत से ज़्यादा memory copy आदि हैं, जो .NET की आधुनिक CoreCLR JIT optimization से स्पष्ट रूप से पीछे हैं
- अगर Unity CoreCLR-आधारित .NET modernization पूरा कर लेता है, तो game और editor दोनों में बड़ा performance improvement संभव है, और इससे सभी Unity projects पर लगने वाला छिपा performance tax हट सकता है
Unity में Mono इस्तेमाल होने की पृष्ठभूमि
- Unity 2006 से C# कोड चलाने के लिए Mono framework का इस्तेमाल कर रहा है
- उस समय Mono ही एकमात्र multi-platform .NET implementation था, और open source होने के कारण Unity उसमें बदलाव कर सकता था
- 2014 के बाद Microsoft ने .NET Core को open source किया, और 2016 में .NET Core 1.0 जारी किया
- इसके बाद Roslyn compiler, नया JIT, performance improvements आदि के साथ .NET ecosystem तेज़ी से आगे बढ़ा
- 2018 में Unity engineers ने बताया था कि वे CoreCLR porting पर काम कर रहे हैं, और Mono की तुलना में 2 से 10 गुना performance improvement की उम्मीद है
- लेकिन 2025 के अंत तक भी CoreCLR-आधारित game execution संभव नहीं है
Mono और .NET के बीच performance gap
- Unity project के simulation code को Unity के बाहर .NET पर चलाकर सीधी तुलना की गई
- Unity/Mono environment: 100 सेकंड, .NET environment: 38 सेकंड (Debug mode के आधार पर)
- Release mode में Mono 30 सेकंड और .NET 12 सेकंड रहा, यानी अंतर बरकरार है
- .NET, 4K×4K map को 3 सेकंड के भीतर generate कर देता है, जो इसकी multithread optimization क्षमता दिखाता है
- Mono का अप्रभावी code generation एक बड़ी वजह है, और साधारण loop में भी 15 गुना speed difference देखा गया
Assembly तुलना: Mono vs .NET
- एक ही test code से बने x64 assembly की तुलना में पाया गया कि
- .NET JIT loop invariants को loop के बाहर ले जाता है (hoisting) और केवल न्यूनतम register operations करता है
- Mono दर्जनों
mov instructions के साथ memory copy दोहराता है, और अप्रभावी inlining के कारण performance गिरती है
int.MaxValue repeat loop execution time
- .NET: 750ms, Mono: 11,500ms, Unity Editor(Debug): 67,000ms
- Mono loop के भीतर अनावश्यक memory move और comparison operations बार-बार चलाता है
CoreCLR अपनाने का महत्व
- CoreCLR आधुनिक JIT, Span<T> API, SIMD optimization, hardware instruction support जैसी modern capabilities देता है
- इनसे अतिरिक्त 2 गुना या उससे अधिक performance improvement की संभावना है
- Unity का Burst compiler LLVM-आधारित native code बनाता है, लेकिन इसमें C# feature limitations हैं
- CoreCLR का modern JIT, Burst जैसी performance दे सकता है और इसमें language restrictions कम हैं
- CoreCLR, AOT (ahead-of-time compilation) support भी देता है, जिससे startup speed improvement और JIT-सीमित platforms (जैसे iOS) के लिए समर्थन संभव है
- फिर भी Unity ने अभी IL2CPP बनाए रखने की नीति बताई है
निष्कर्ष: Unity को .NET modernization की ज़रूरत
- Mono, आधुनिक .NET की तुलना में 1.5 से 3 गुना या उससे अधिक धीमी execution performance दिखाता है, और यह सभी Unity projects पर एक छिपी हुई लागत की तरह असर डालता है
- CoreCLR आने पर संभावित लाभ
- runtime performance improvement, तेज़ iterative builds, GC improvement, domain reload हटना, managed code usage बढ़ना
- Unity 6.x roadmap में .NET Modernization शामिल है, लेकिन यह 2026 के बाद के लिए निर्धारित है
- CoreCLR support पूरा होने पर Unity developers और players दोनों को वास्तविक performance transformation मिल सकता है
- फिलहाल Mono की सीमाएँ पूरे Unity ecosystem की performance bottleneck बनी हुई हैं
अभी कोई टिप्पणी नहीं है.