TL; DR — इलेक्ट्रॉन में असली मेमोरी लागत होती है। इसे एक महत्वपूर्ण रिकॉर्डिंग या निर्यात दंड लागू करने की आवश्यकता नहीं है।
हमारे M4 Mac मिनी पर, एक नेटिव ScreenCaptureKit रिकॉर्डर और वही नेटिव रिकॉर्डर जो Electron से होस्ट किया गया था, ने 4K वीडियो 57.70 और 57.53 fps पर बनाया। एक 4K एडिटिंग शेडर ने डायरेक्ट मेटल में फ़्रेम पर p95 पर 1.62 ms और Electron के WebGL-टू-मेटल पथ के माध्यम से 1.90 ms लिया। एक नियंत्रित 1080p H.264 एक्सपोर्ट नेटिव VideoToolbox के माध्यम से 7.54x वास्तविक समय और Electron के WebCodecs पथ के माध्यम से 7.46x पर चला।
अंतर शून्य नहीं था। यह सिर्फ वह जगह नहीं थी जहाँ पारंपरिक तर्क इसे रखता है।
इलेक्ट्रॉन का स्पष्ट नुकसान मेमोरी था: सीधे नेटिव रिकॉर्डिंग होस्ट के लिए 45 MB बनाम क्रोमियम रेंडरर जोड़ने से पहले साइन किए गए इलेक्ट्रॉन/नोड होस्ट के लिए 94 MB। इस परीक्षण में एक पैकेज्ड Tight Studio सत्र लगभग 744–749 MB के आसपास स्थिर हो गया। यह एक व्यापारिक समझौता है जिसे ईमानदारी से नाम देना लायक है। यह इस बात का सबूत नहीं है कि कैप्चर किए गए फ्रेम्स को वेब पेज के माध्यम से जाना आवश्यक है या कि एक्सपोर्ट को सॉफ्टवेयर एन्कोडिंग पर लौटना चाहिए।
हम Electron के साथ Tight Studio बनाते हैं, इसलिए इस सवाल में हमारी रुचि है। यही कारण है कि हमने बेंचमार्क को नियंत्रित और दोहराने योग्य बनाया, और यही कारण है कि इस पोस्ट में ऐसे परिणाम शामिल हैं जो Electron को खराब दिखाते हैं साथ ही ऐसे परिणाम भी जो इसे अच्छा दिखाते हैं।
“नेटिव बनाम इलेक्ट्रॉन” गलत अमूर्तन का स्तर है
एक डेस्कटॉप एप्लिकेशन एक निष्पादन इंजन नहीं है।
इलेक्ट्रॉन एक क्रोमियम रेंडरर, एक Node. js मुख्य प्रक्रिया, और एक मल्टीप्रोसेस एप्लिकेशन शेल प्रदान करता है। यह नेटिव मॉड्यूल्स का भी समर्थन करता है। इलेक्ट्रॉन के खुद के दस्तावेज़ स्पष्ट रूप से बताते हैं कि एक ऐप प्लेटफ़ॉर्म API और प्रदर्शन-संबंधित कार्यों के लिए नेटिव कोड का उपयोग कर सकता है।
इसका मतलब है कि एक इलेक्ट्रॉन स्क्रीन रिकॉर्डर को कम से कम दो बहुत अलग तरीकों से बनाया जा सकता है:
- जावास्क्रिप्ट और ब्राउज़र सतहों के माध्यम से फ्रेम कैप्चर करें, कंपोज़िट करें, कॉपी करें, और एन्कोड करें।
- उत्पाद UI और ऑर्केस्ट्रेशन के लिए इलेक्ट्रॉन का उपयोग करें जबकि ScreenCaptureKit, AVFoundation, Metal, VideoToolbox, या कोई अन्य मूल मीडिया इंजन हॉट पथ का मालिक है।
ये ऐप्स एक फ्रेमवर्क लेबल साझा करते हैं। वे प्रदर्शन वास्तुकला साझा नहीं करते।
इलेक्ट्रॉन पहले से ही मांग वाले डेस्कटॉप ऐप्स को संचालित करता है
यह आर्किटेक्चर असामान्य नहीं है। वर्तमान macOS वितरण Codex और Claude Electron का उपयोग करते हैं। इस लेख के लिए उपयोग की गई मशीन पर, Codex 26.825.41651 घोषित करता है ElectronAsarIntegrity इसके लिए app.asar पैकेज, जबकि Claude 1.26832.0 दोनों शिप करता है Electron Framework.framework और app.asar.
इलेक्ट्रॉन की अपनी ही दस्तावेज़ीकरण में Visual Studio Code, Figma, Docker Desktop, Loom, Canva, Notion, 1Password, Slack, Discord, और Signal का नाम उन उत्पादों में शामिल किया गया है जो फ्रेमवर्क के साथ बनाए गए हैं। ये कोड संपादन और डिबगिंग, सहयोगी ग्राफिक्स, कंटेनर प्रबंधन, स्क्रीन रिकॉर्डिंग, क्रेडेंशियल प्रबंधन, मैसेजिंग, वॉइस और वीडियो, और AI कार्यप्रवाह को कवर करते हैं।
वह सूची प्रदर्शन मानक नहीं है, और यह यह साबित नहीं करती कि हर Electron ऐप प्रभावी है। यह स्थापत्य बिंदु को दिखाती है: डेस्कटॉप शेल के लिए Electron का चयन करने का मतलब यह नहीं है कि शेल हर महंगे संचालन को करने के लिए बाध्य है। मूल मॉड्यूल, GPU प्रक्रियाएं, स्थानीय सेवाएं, और दूरस्थ सिस्टम विशेष कार्यों के लिए जिम्मेदार हो सकते हैं।
आप विशेष उपकरणों के बिना macOS बंडल जांच को पुन: उत्पन्न कर सकते हैं। Finder में, चुनें पैकेज सामग्री दिखाएँ, फिर निरीक्षण करें Contents/Info.plist, Contents/Resources/app.asar, और Contents/Frameworks/.
Tight Studio दूसरा मॉडल उपयोग करता है। macOS पर, स्क्रीन फ्रेम्स को ScreenCaptureKit का उपयोग करके एक Swift मॉड्यूल द्वारा कैप्चर किया जाता है और AVAssetWriter के साथ लिखा जाता है। रिकॉर्डिंग DOM, React, या Chromium कैनवास के माध्यम से नहीं जाती। संपादन और निर्यात के दौरान, GPU कॉम्पोज़िटिंग और हार्डवेयर कोडेक API महंगा काम करते हैं; JavaScript पाइपलाइन का समन्वय करता है।
एप्पल ScreenCaptureKit को फ्रेम और ऑडियो कैप्चर के लिए अपने उच्च-प्रदर्शन API के रूप में वर्णित करता है। इलेक्ट्रॉन किसी ऐप को इसे कॉल करने से रोकता नहीं है। एक नेटिव मॉड्यूल समान फ्रेमवर्क को कॉल कर सकता है, समान प्राप्त कर सकता है CMSampleBuffer ऑब्जेक्ट्स, और उन्हें उसी सिस्टम एन्कोडर को सौंपें।
हमने क्या बेंचमार्क किया
हमने दो समाप्त उत्पादों की तुलना करने से बचा। एक ऐप कैप्शन, कर्सर की गति, कैमरा कटआउट और पांच ओवरले रेंडर कर सकता है जबकि दूसरा मूल रिकॉर्डिंग को रीमिक्स करता है। तेज़ परिणाम हमें Swift या Electron के बारे में लगभग कुछ भी नहीं बताएगा।
इसके बजाय, हमने कार्यभार को स्थिर रखा:
- मशीन: एपल M4 Mac मिनी, 10-कोर CPU, 10-कोर GPU, 16 GB मेमोरी, macOS 26.5.2.
- रिकॉर्डिंगः सही वही पैकेज्ड नेटिव कैप्चर इंजन, एक बार इसे सीधे Swift CLI से चलाया गया और एक बार Tight Studio के साइन किए गए Electron/Node executable से। दोनों ने 60 fps लक्ष्य पर समान एनिमेटेड 3840×2160 डिस्प्ले रिकॉर्ड किया।
- संपादन: समान प्रक्रियात्मक पृष्ठभूमि, गोलाकार कार्ड, ग्रिड, छाया, और 3840×2160 पर एनिमेटेड कर्सर शेडर। नेटिव ने मेटल का उपयोग किया; इलेक्ट्रॉन ने ANGLE के मेटल रेंडरर के माध्यम से WebGL 2 का उपयोग किया। हर फ्रेम में एक समन्वय सीमांत था ताकि एक छिपा हुआ कैनवास काम को गायब न कर सके।
- निर्यात: 1920×1080 में 300 फ्रेम, 30 fps, H.264, और 12 Mbps लक्ष्य। नेटिव ने मेटल प्लस वीडियो टूलबॉक्स का उपयोग किया। इलेक्ट्रॉन ने हार्डवेयर एक्सेलेरेशन के अनुरोध के साथ WebGL प्लस WebCodecs का उपयोग किया।
- चलाएँ: प्रति पथ तीन। तालिका माध्य को रिपोर्ट करती है।
कोई बैटरी परिणाम शामिल नहीं है। यह एक Mac मिनी था, और एक विश्वसनीय बैटरी दावा लंबे, नियंत्रित MacBook परीक्षण की आवश्यकता है।
परिणाम
| चरण | सीधा लोकल | इलेक्ट्रॉन/हाइब्रिड | इलेक्ट्रॉन का अंतर |
|---|---|---|---|
| 4K रिकॉर्डिंग आउटपुट दर | 57.70 फ़्रेम प्रति सेकंड | 57.53 फ़्रेम प्रति सेकंड | -0.29% |
| होस्ट रिकॉर्डिंग CPU | 7.06% | 6.98% | -0.09 अंक |
| रिकॉर्डिंग OS-सेवा CPU | 31.34% | 32.76% | +1.42 अंक |
| होस्ट पीक मेमोरी रिकॉर्डिंग | 45.36 MB | 94.39 MB | +49.03 MB |
| 4K शेडर थ्रूपुट संपादित करें | 684.23 फ़्रेम प्रति सेकंड | 593.77 फ़्रेम प्रति सेकंड | -13.22% |
| 4K छायाचित्र p95 फ्रेम समय संपादित करें | 1.62 मिलीसेकंड | 1.90 मिलीसेकंड | +0.28 मिलीसेकंड |
| 1080p निर्यात थ्रूपुट | 226.10 fps | 223.78 fps | -1.02% |
| 1080p निर्यात गति | 7.54x वास्तविक समय | 7.46x वास्तविक समय | -1.02% |
ये छोटे, नियंत्रित परीक्षण हैं एक मशीन पर। ये स्थापित करते हैं कि इन आर्किटेक्चर के साथ क्या संभव है; ये यह वादा नहीं करते कि हर Electron ऐप इतनी कुशल होगी।
रिकॉर्डिंग: इलेक्ट्रॉन को फ्रेम को छूने की जरूरत नहीं है
रिकॉर्डिंग परिणाम लगभग बराबरी पर है क्योंकि दोनों पाथ वही हैं जहां यह महत्वपूर्ण होता है।
ScreenCaptureKit फ्रेम्स उत्पन्न करता है। AVAssetWriter और सिस्टम कोडेक स्टैक उन्हें एनकोड करता है। Electron साइड देशी रिकॉर्डर से शुरू करने, रोकने, पॉज़ करने और फिर से शुरू करने के लिए कहती है। इसे 4K पिक्सेल बफ़र IPC चैनल के माध्यम से नहीं मिलते और इसे JavaScript में एनकोड नहीं किया जाता।
तीन रन के दौरान, नेटिव ने औसतन 57.70 एफपीएस और इलेक्ट्रॉन होस्ट ने 57.53 एफपीएस प्रदान किया—0.29% का अंतर। माध्यम रिकॉर्डर CPU नेटिव के लिए 7.06% और इलेक्ट्रॉन होस्ट के लिए 6.98% था। macOS कैप्चर सेवाओं का औसत क्रमशः 31.34% और 32.76% था।
फ्रेम-रेट परिणाम महत्वपूर्ण है। छोटा CPU रिवर्सल सामान्य रन-टू-रन शोर है, यह सबूत नहीं कि इलेक्ट्रॉन किसी तरह ScreenCaptureKit को तेज करता है।
एक परीक्षण संबंधी झुर्रियों के बारे में बताना महत्वपूर्ण है। macOS ने साइन की गई एप्लिकेशन पहचान को स्क्रीन रिकॉर्डिंग अनुमति दी। हमारी विकास Electron बाइनरी के पास वह अनुमति नहीं थी, इसलिए Electron रिकॉर्डिंग रन ने Electron के Node-संगत मोड में Tight Studio के साइन किए गए निष्पादन योग्य फ़ाइल का उपयोग किया। इससे देशी ब्रिज अलग हो जाता है लेकिन एक Chromium रेंडरर को छोड़ दिया जाता है। हमने पैक किए गए शेल को अलग से मापा बजाय इसके कि 94 MB होस्ट को पूरी Electron ऐप के रूप में चुपचाप प्रस्तुत किया जाए।
संपादन: अनुवादित मेटल अभी भी मेटल है
जावास्क्रिप्ट सीधे एप्पल के मेटल API को एक्सपोज़ नहीं करता। यह तथ्य कभी-कभी एक बहुत बड़े दावे में बढ़ा दिया जाता है: कि इलेक्ट्रॉन मेटल-बैक्ड GPU रेंडरिंग का उपयोग नहीं कर सकता।
macOS को ANGLE, OpenGL ES के लिए एक मेटल बैकएंड प्रदान करता है, जिसका उपयोग Chromium WebGL के तहत कर सकता है। हमारे Electron बेंचमार्क ने इसके रेंडरर को पहचान लिया है ANGLE Metal Renderer: Apple M4.
डायरेक्ट मेटल तेज़ था। माध्य लोकल रन ने प्रति सेकंड 684 फ्रेम प्रस्तुत किए; इलेक्ट्रॉन ने 594 फ्रेम प्रस्तुत किए, 13% थ्रूपुट अंतर। P95 फ्रेम समय 1.62 से बढ़कर 1.90 मिलीसेकंड हो गया।
यह मापनीय ओवरहेड है। यह 60 fps पर 16.67 ms के फ्रेम बजट में 0.28 ms भी है।
असली संपादक बेशक एक से अधिक शेडर करते हैं। वे वीडियो को डिकोड करते हैं, टेक्सचर अपलोड या इम्पोर्ट करते हैं, टेक्स्ट रेंडर करते हैं, एनिमेशन स्थिति की गणना करते हैं, और इनपुट का जवाब देते हैं। एक लापरवाह कार्यान्वयन बाकी बजट को कॉपी, एलोकेशन, समकालिक IPC, या React कार्य से जल सकता है। लेकिन ब्राउज़र कंपोज़िटर स्वतः ही सॉफ़्टवेयर रेंडरर नहीं है, और Mac पर WebGL यह प्रमाण नहीं है कि GPU को बाईपास कर दिया गया है।
जब कोई WebGL या WebGPU पथ पर्याप्त नहीं होता है, Electron अभी भी एक मूल Metal मॉड्यूल की अनुमति देता है। आर्किटेक्चर प्रत्येक सबसिस्टम के लिए अपना निकास मार्ग चुन सकता है।
निर्यात: हार्डवेयर एन्कोडर को परवाह नहीं है कि किस बटन ने इसे शुरू किया
VideoToolbox हार्डवेयर एन्कोडर और डिकोडर के लिए एप्पल का निम्न-स्तरीय इंटरफ़ेस है। क्रोमियम में एक macOS VideoToolbox एन्कोडर बैकएंड है, और WebCodecs एप्लिकेशन को हार्डवेयर-त्वरण प्राथमिकता प्रदान करता है।
हमारी मूल रन में, VideoToolbox ने हार्डवेयर एन्कोडिंग की पुष्टि की। Electron रन ने वेबकोडेक्स के माध्यम से हार्डवेयर का अनुरोध किया। WebCodecs चयनित एन्कोडर का नाम उजागर नहीं करता, इसलिए हम API-स्तर का Electron चयन का प्रमाण नहीं दे सकते। इसका प्रदर्शन और आउटपुट हार्डवेयर पथ के समान है: मूल रूप से एन्कोड किए गए 300 फ्रेम औसत 1.327 सेकंड में; Electron ने 1.341 सेकंड लिए। आउटपुट का आकार 1% से कम में भिन्न था।
यह वास्तविक समय में 7.54x बनता है बनाम 7.46x—1% का अंतर।
इसका मतलब यह नहीं है कि हर Electron एक्सपोर्टर तेज है। जब कोई ऐप ऐसा करता है तो एक्सपोर्ट धीमा हो जाता है:
- हर फ़्रेम के लिए GPU से पिक्सेल वापस पढ़ता है;
- पूर्ण फ्रेम्स को जावास्क्रिप्ट या IPC के माध्यम से कॉपी करता है;
- सॉफ़्टवेयर में एनकोड करता है;
- अनावश्यक रूप से डिकोड, रेंडर, ऑडियो और एन्कोड चरणों को क्रमबद्ध करता है;
- पूरा आउटपुट स्ट्रीमिंग करने के बजाय मेमोरी में रखता है;
- UI थ्रेड को रेंडर वर्कर के रूप में उपयोग करता है।
ये पाइपलाइन विकल्प हैं, Electron द्वारा लगाई गई आवश्यकताएँ नहीं।
एक वास्तविक Tight Studio एक्सपोर्ट
माइक्रोबेंचमार्क दिखाते हैं कि ओवरहेड कहाँ प्रवेश करता है। एक उत्पाद परीक्षण हमें बताता है कि पूरी पाइपलाइन उपयोगी है या नहीं।
हमने Tight Studio के मौजूदा पाँच-क्लिप निर्यात प्रतिगमन फ़िक्सचर को तीन बार भी चलाया। 112-सेकंड की टाइमलाइन प्रति-क्लिप डिकोड, GPU रेंडरिंग, ऑडियो, एन्कोडिंग, संयोजन और 1440×1080 पर मक्सिंग का अभ्यास करती है। निर्यात समय 81.54, 80.94 और 81.28 सेकंड थे। माध्यक 81.28 सेकंड था, या 1.38x वास्तविक समय।
जेनरेट किया गया फ़ाइल 112.36 सेकंड लंबा था, लगभग 30 fps, H.264 वीडियो और AAC ऑडियो के साथ। यह फिक्स्चर सार्वभौमिक एक्सपोर्ट-स्पीड स्कोर नहीं है—स्रोत मीडिया और इफ़ेक्ट्स मायने रखते हैं—लेकिन यह एक एंड-टू-एंड इलेक्ट्रॉन एप्लिकेशन है जो रिपीटेबल रिपॉजिटरी टेस्ट में प्लेबैक से तेज़ी से एक्सपोर्ट कर रहा है।
वास्तव में इलेक्ट्रॉन क्या खो देता है: मेमोरी
इलेक्ट्रॉन एक मल्टीप्रोसेस ब्राउज़र रनटाइम को एम्बेड करता है। इसका खर्चा मेमोरी पर होता है।
प्रत्यक्ष स्थानीय रिकॉर्डिंग होस्ट 45 MB RSS पर पहुँच गया। साइन किए गए इलेक्ट्रॉन/नोड होस्ट 94 MB पर पहुँचा। हमारी न्यूनतम इलेक्ट्रॉन संपादन प्रक्रिया पेड़ करीब 360 MB था, और निर्यात प्रक्रिया पेड़ करीब 394 MB था। एक नया प्रोफ़ाइल वाला पैकेज किया गया Tight Studio सत्र इस विशेष ऐप स्थिति में लगभग 744–749 MB पर स्थिर हुआ।
वह आखिरी संख्या Electron का नियम नहीं है, और यह देशी ऐप तुलना नहीं है। यह याद दिलाने के लिए है कि न्यूनतम परीक्षण शेल का मार्केटिंग आड़ में उपयोग न करें।
सीमित मशीनों में मेमोरी मायने रख सकती है। यह दबाव पैदा कर सकती है, स्वैप बढ़ा सकती है, और अप्रत्यक्ष रूप से ऊर्जा की लागत बढ़ा सकती है। लेकिन आबंटित RAM रिकॉर्ड की गई CPU, छोड़े गए फ्रेम, GPU फ्रेम समय, या एन्कोडर थ्रूपुट के समान मीट्रिक नहीं है। किसी एक को सभी के लिए प्रतिनिधि मानकर व्यवहार करना खराब इंजीनियरिंग निष्कर्ष देता है।
व्यावहारिक लक्ष्य यह नहीं है कि “कोई क्रोमियम मेमोरी न इस्तेमाल करें। ” लक्ष्य यह है कि ब्राउज़र रनटाइम को रॉ-फ़्रेम हॉट पाथ से दूर रखा जाए, मीडिया ऑब्जेक्ट्स को तुरंत बंद किया जाए, बफ़र्स को सीमित किया जाए, आउटपुट को स्ट्रीम किया जाए, और खाली काम को खाली रखा जाए।
एक स्क्रीन रिकॉर्डर का मूल्यांकन करने का एक बेहतर तरीका
पूछें कि प्रत्येक सबसिस्टम वास्तव में क्या करता है:
- कौन सा API स्क्रीन को कैप्चर करता है?
- फ्रेम्स कहां कंपोज़िट किए जाते हैं?
- क्या GPU का बैकएंड हार्डवेयर एक्सेलेरेटेड है?
- कौन सा एन्कोडर इम्प्लीमेंटेशन चुना गया है?
- कितनी फुल-फ्रेम कॉपी होती हैं?
- क्या पिक्सल डेटा IPC या जावास्क्रिप्ट सीमाओं को पार करता है?
- क्या संपादक लक्ष्य रिज़ॉल्यूशन पर 60 fps बनाए रख सकता है?
- आउटपुट के प्रति सेकंड निर्यात समय क्या है?
- एक ही वर्कलोड पर CPU, मेमोरी, ड्रॉप-फ्रेम, पावर और थर्मल परिणाम क्या हैं?
“नेटिव” और “इलेक्ट्रॉन” उपयोगी कार्यान्वयन विवरण हैं। वे कमजोर बेंचमार्क परिणाम हैं।
निष्कर्ष
एक पूरी तरह से मूल एप्लिकेशन में सबसे कम संभव शेल ओवरहेड और प्लेटफ़ॉर्म एपीआई तक सबसे सीधी पहुँच होती है। यदि दो टीमें उत्तम रूप से अनुकूलित, विशेषता-एक समान पाइपलाइन बनाती हैं, तो मूल हमेशा एक लाभ बनाए रखता है—विशेष रूप से स्मृति में और GPU नियंत्रण के अंतिम अंशों में।
लेकिन एक इलेक्ट्रॉन ऐप को अपने मीडिया इंजन को DOM नोड्स और जावास्क्रिप्ट लूप्स से बनाने की आवश्यकता नहीं है। यह ScreenCaptureKit के माध्यम से कैप्चर कर सकता है, Metal-समर्थित GPU एपीआई पर कंपोज़िट कर सकता है, हार्डवेयर मीडिया इंजन के साथ एन्कोड कर सकता है, और प्रदर्शन-संवेदनशील काम को नेटिव मॉड्यूल्स या वर्कर्स में स्थानांतरित कर सकता है।
हमारे मापों में 0.29% रिकॉर्डिंग-फ्रेम-रेट गैप, 13% सिंथेटिक 4K शेडर-थ्रूपुट गैप, और 1% नियंत्रित निर्यात गैप पाया गया। हमने एक बड़ी मेमोरी गैप भी पाई। यही व्यापार-बंदोबस्त की ईमानदार स्थिति है।
फ्रेमवर्क डिफ़ॉल्ट सेट करता है। पाइपलाइन प्रदर्शन निर्धारित करती है।
स्रोत और प्रजनन
- एप्पल: ScreenCaptureKit
- एप्पल: VideoToolbox
- electron: नेटिव कोड और इलेक्ट्रॉन
- electron: प्रोसेस मॉडल
- इलेक्ट्रॉन: क्यों इलेक्ट्रॉन और प्रोडक्शन ऐप उदाहरण
- ANGLE: मेटल बैकएंड सपोर्ट
- chromium: macOS videotoolbox एन्कोडर
- W3C: WebCodecs हार्डवेयर त्वरण
बेंचमार्क हार्नेस, रॉ रन टेबल, अनुमति चेतावनी, और व्याख्या सीमाएँ एक स्टैंडअलोन सार्वजनिक रिलीज़ के लिए तैयार की जा रही हैं। जब पैकेज को स्वतंत्र रूप से क्लोन और रन किया जा सकेगा, तब हम यहाँ रिपॉज़िटरी लिंक जोड़ेंगे। अतिरिक्त एप्पल सिलिकॉन मशीनें और एक नियंत्रित MacBook पावर टेस्ट इन परिणामों को विस्तारित करेंगे, लेकिन इन्हें ऊपर दिए गए दावों में शामिल नहीं किया गया है।