Performance | The .NET Blog

.NET 11 ने अंततः प्रोसेस API को ठीक किया

Emiliano Montesdeoca — Tue, 26 May 2026 00:00:00 +0000

हर .NET डेवलपर जिसे कभी एक प्रोसेस शुरू करके उसका आउटपुट कैप्चर करना पड़ा है, उसने उसी खतरनाक बॉयलरप्लेट कोड का कोई न कोई वेरिएशन लिखा है: stdout से async रीड, stderr से async रीड, WaitForExitAsync, दोनों स्ट्रीम को ड्रेन करना न भूलें वरना डेडलॉक हो जाएगा। यह एक जानी-पहचानी समस्या है जो वर्षों से चली आ रही है।

.NET 11 अंततः इसे सही ढंग से ठीक करता है।

RunAndCaptureTextAsync

मुख्य जोड़: एक सिंगल स्टैटिक मेथड जो एक प्रोसेस शुरू करता है, stdout और stderr कैप्चर करता है, और डेडलॉक के बिना एग्जिट का इंतजार करता है।

var result = await Process.RunAndCaptureTextAsync("dotnet", "--version");
Console.WriteLine(result.StandardOutput);

एक कॉल। कोई मैनुअल स्ट्रीम ड्रेनिंग नहीं। कोई सावधानी से रखा गया WaitForExit नहीं। अगर आपको बस कुछ रन करना है और उसका आउटपुट चाहिए, तो यही वो API है।

आउटपुट कैप्चर किए बिना एग्जिट का इंतजार करने के लिए Process.RunAsync भी है।

KillOnParentExit

शुरू किए गए प्रोसेस की एक सामान्य समस्या: अगर पैरेंट क्रैश हो जाए या बंद हो जाए, तो चाइल्ड प्रोसेस अनाथ की तरह चलते रहते हैं। KillOnParentExit आपको प्रोसेस शुरू करते वक्त घोषित करने देता है कि पैरेंट प्रोसेस के बंद होने पर चाइल्ड प्रोसेस भी बंद हो जाए।

यह एक ऐसी सुविधा थी जो प्लेटफॉर्म-विशिष्ट तरीकों से मौजूद थी (Windows पर job objects, Linux पर prctl) लेकिन .NET से इस्तेमाल करने के लिए p/invoke या थर्ड-पार्टी लाइब्रेरी की जरूरत थी। अब यह ProcessStartInfo पर एक फर्स्ट-क्लास प्रॉपर्टी है।

SafeProcessHandle-आधारित API

नई लाइटवेट API सर्फेस पूर्ण Process क्लास के बजाय SafeProcessHandle के आसपास बनाई गई है। पूर्ण Process क्लास बहुत सारी स्थिति लेकर चलती है और इसे ट्रिम करना मुश्किल है — SafeProcessHandle पाथ उन एप्लीकेशन के लिए ज़्यादा ट्रिमर-फ्रेंडली है जिन्हें आउटपुट साइज़ कम करनी है (WASM, नेटिव AOT)।

हैंडल इनहेरिटेंस पर पूरा नियंत्रण

अपडेट में यह भी जोड़ा गया है कि एक चाइल्ड प्रोसेस कौन से हैंडल इनहेरिट करता है और स्टैंडर्ड हैंडल कैसे रीडायरेक्ट होते हैं, इस पर बारीक नियंत्रण। पहले आप stdin/stdout/stderr रीडायरेक्ट कर सकते थे, लेकिन OS स्तर पर ठीक-ठीक कौन से हैंडल इनहेरिट करने हैं यह नहीं बता सकते थे। नई APIs वो नियंत्रण देती हैं।

यह क्यों मायने रखता है

Process क्लास tooling, build सिस्टम, test रनर, और किसी भी एप्लीकेशन में उपयोग होती है जो अन्य executables को कॉल करती है। पुरानी API सर्फेस .NET Framework के ज़माने की थी। यह कोई ब्रेकिंग चेंज नहीं है — पुरानी API काम करती रहती है — लेकिन नए कोड को नई सर्फेस को प्राथमिकता देनी चाहिए।

ट्रिम्ड एप्लीकेशन या AOT कंपाइलेशन परिदृश्यों के लिए, SafeProcessHandle पाथ विशेष रूप से स्वागत योग्य है। पुरानी Process क्लास बहुत सारा reflection-heavy कोड लाती थी जो ट्रिमिंग को जटिल बनाता था।

मूल पोस्ट: Process API Improvements in .NET 11

Copilot Studio ने .NET 10 WebAssembly में माइग्रेट करके 20% तेज़ गति कैसे प्राप्त की

Emiliano Montesdeoca — Sat, 23 May 2026 00:00:00 +0000

Copilot Studio टीम ने वह किया जिसके बारे में सभी Blazor WASM डेवलपर उत्सुक थे: उन्होंने वास्तव में एक प्रोडक्शन एप्लिकेशन को .NET 8 से .NET 10 में अपग्रेड किया और परिणाम मापे। पोस्ट में विशिष्ट संख्याएं साझा की गई हैं, जो दुर्लभ और वास्तव में उपयोगी है।

अपग्रेड उबाऊ था (यह एक अच्छी बात है)

टार्गेट फ्रेमवर्क अपडेट करना, पैकेज संदर्भ ताज़ा करना, ब्रेकिंग बदलाव ठीक करना। बस इतना ही। .NET 10 बिल्ड अब प्रोडक्शन में चल रहा है। माइग्रेशन खुद दिलचस्प हिस्सा नहीं था — .NET 10 में बदलाव हैं।

स्वचालित एसेट फिंगरप्रिंटिंग

पहले, WASM ऐप वितरित करने का मतलब था कैश-बस्टिंग के लिए SHA256 हैश के साथ प्रकाशित एसेट का नाम बदलने के लिए कस्टम स्क्रिप्ट लिखना। Copilot Studio के पास एक PowerShell स्क्रिप्ट थी जो ठीक यही करती थी — फ़ाइलें रीनेम करना, JavaScript लोडर में integrity विशेषताएं इंजेक्ट करना, सब कुछ मैन्युअल रूप से प्रबंधित करना।

.NET 10 में, यह सब अंतर्निहित है। प्रकाशित एसेट स्वचालित रूप से फिंगरप्रिंट किए जाते हैं, सीधे dotnet.js से आयात किए जाते हैं, और मैन्युअल हस्तक्षेप के बिना अखंडता-सत्यापित होते हैं। टीम ने रीनेमिंग स्क्रिप्ट हटा दी।

दायरे में छोटा बदलाव, जटिलता में महत्वपूर्ण कमी।

WasmStripILAfterAOT अब डिफ़ॉल्ट रूप से चालू

.NET 8 में, AOT-कंपाइल असेंबली से IL हटाना ऑप्ट-इन था। .NET 10 में यह डिफ़ॉल्ट है। AOT संकलन के बाद, मूल IL बाइटकोड आउटपुट से हटा दिया जाता है — रनटाइम पर इसकी आवश्यकता नहीं होती, और इसे रखने से पैकेज साइज़ बिना कारण बढ़ता था।

Copilot Studio एक विशिष्ट अनुकूलन का उपयोग करता है: यह JIT इंजन (तेज़ स्टार्टअप) और AOT इंजन (अधिकतम स्टेडी-स्टेट प्रदर्शन) दोनों वितरित करता है, दोनों को समानांतर में लोड करता है और तैयार होने पर JIT से AOT में हैंडऑफ़ करता है। यह दोनों इंजनों के बीच समान फ़ाइलों को भी डीडुप्लीकेट करता है।

नया IL स्ट्रिपिंग व्यवहार इसका मतलब है कि AOT असेंबली अब अपने JIT समकक्षों के साथ बिट-फॉर-बिट मेल नहीं खाती, इसलिए कम फ़ाइलें डीडुप्लीकेट होती हैं:

.NET 8: 59 साझा फ़ाइलें
.NET 10: 22 साझा फ़ाइलें

शुद्ध परिणाम: AOT इंजन के लिए पैकेज साइज़ लगभग 15% बड़ा। AOT डाउनलोड तेज़ LAN पर ~6% धीमा, 4G पर ~17% धीमा। लेकिन यह सब ऐप के इंटरैक्टिव हो जाने के बाद पृष्ठभूमि में होता है।

प्रदर्शन संख्याएं

यह वह हिस्सा है जो मायने रखता है:

पहली कॉल पर ~20% तेज़ (कोल्ड पाथ)
बाद की कॉल पर ~5% तेज़ (वार्म पाथ)

“बड़े बॉट्स” में सुधार सबसे अधिक दिखाई देते हैं — बड़े, जटिल एजेंट जहां AOT-कंपाइल कोड हावी है। सरल वर्कफ़्लो के लिए लाभ छोटा है।

यदि आप अभी भी .NET 8 पर हैं

माइग्रेशन की कहानी वास्तव में सरल है: <TargetFramework> अपडेट करें, पैकेज संदर्भ अपडेट करें, कोई भी कस्टम फिंगरप्रिंटिंग स्क्रिप्ट हटाएं, और आप स्वचालित रूप से WasmStripILAfterAOT से लाभ उठाएंगे। यदि आप AOT कंपाइल कर रहे हैं, तो समान प्रदर्शन लाभ की उम्मीद करें।

पोस्ट से एक नोट: यदि आप WebWorker के अंदर .NET WASM रनटाइम लोड करते हैं, तो इनिशियलाइज़ करते समय dotnetSidecar = true सेट करें।

मूल पोस्ट: Copilot Studio gets faster with .NET 10 on WebAssembly