प्रदर्शन रिपोर्ट

NSH ऐप्स की लागत, मापी हुई। NSH उन्हें तेज़ कैसे रखता है और अपने ऐप को कैसे मापें, यह Performance में है।

#बेसलाइन

NSH के अपने बेसलाइन से (जब तक अन्यथा न लिखा हो, Apple silicon):

#Linux (GTK 4)

एक Linux डेस्कटॉप (x86_64, 24 थ्रेड, NVIDIA GPU) पर मापा गया, release बिल्ड, 120 Hz डिस्प्ले पर 1896 × 1030 विंडो में gallery, हर रीडिंग examples/gallery/tools/perf.py (nsh test --target linux --fps, हर सेकंड एक पंक्ति) द्वारा अपने-आप ली गई; CPU पूरी प्रोसेस का है, एक कोर के प्रतिशत में। Frame p95 प्रति बनाए गए फ़्रेम पर मुख्य थ्रेड का समय है, 95वें परसेंटाइल पर: 8.3 ms से कम होने पर फ़्रेम 120 Hz रिफ़्रेश में समा जाता है।

#एनिमेटेड डेमो

#हर पेज

Gallery का हर पेज, खुलते समय और टेस्ट द्वारा स्क्रॉल किए जाने के दौरान, 144 Hz डिस्प्ले पर 1200 × 800 विंडो में (वही मशीन)। NSH फ़्रेम तभी बनाता है जब स्क्रीन पर कुछ बदलता है, इसलिए यहाँ FPS वह दर है जब कुछ हिल रहा हो: बनाए गए फ़्रेमों के बीच के median अंतराल पर एक फ़्रेम (perf.py का moving); डिस्प्ले के 144 पर, किसी एनिमेशन या स्क्रॉल का हर फ़्रेम पिछले के एक रिफ़्रेश बाद आता है। Over one refresh उन फ़्रेमों का हिस्सा है जिन्होंने एक रिफ़्रेश (6.9 ms) से ज़्यादा समय लिया। Images के GIF और WebP अपनी फ़्रेम दरों पर चलते हैं (यहाँ लगभग 50 FPS), वीडियो भी। Physics, Overlays और Menus छोटे पेज हैं: 1200 × 800 में स्क्रॉल कुछ ही फ़्रेमों में उनके अंत तक पहुँच जाता है, इसलिए उन्हें 900 × 500 विंडो में मापा गया है, जहाँ उनके पास स्क्रॉल करने की जगह है।

#मेमोरी

आराम की स्थिति में, स्टार्ट के 3 s बाद (release runners, 480 × 640 विंडो)। Private वह मेमोरी है जिसकी मालिक अकेली प्रोसेस है (USS); resident में साझा लाइब्रेरियों (GTK, GPU ड्राइवर) के पेज भी जुड़ते हैं, जिन्हें मशीन का हर GTK ऐप साझा करता है:

किसी पेज पर दोबारा जाने से मेमोरी नहीं बढ़ती; किसी पेज की पहली विज़िट प्रोसेस को उतना बढ़ाती है जितना वह जानबूझकर cache करता है (decoded images, 128 MB तक सीमित) और जितनी लाइब्रेरियाँ वह पहले उपयोग पर लोड करता है (वेब व्यू के लिए WebKitGTK)।

#ऐप का आकार

nsh init द्वारा हर template से बनाया गया एक hello world ऐप, और दो ऐसे ऐप जिन्हें लोग उपयोग करते हैं, जैसा nsh package --target linux उन्हें x86_64 के लिए बनाता है। Runner ऐप की एकमात्र executable है; archive वह .tar.gz है जिसके रूप में वह भेजा जाता है। Hello world को link-time optimization के साथ बनाया गया है और strip किया गया है (CARGO_PROFILE_RELEASE_LTO=fat, CARGO_PROFILE_RELEASE_CODEGEN_UNITS=1, CARGO_PROFILE_RELEASE_STRIP=true):

TSX runners में QuickJS runtime, native modules और renderer शामिल हैं; ऐप का अपना कोड runner के बगल में उसका bundle है, जो hello world के लिए 1 KB से कम है।

ये आँकड़े किससे बनते हैं:

• Renderer: NVIDIA के ड्राइवर पर NSH, GSK के GL renderer से ड्रॉ करता है, जिसके फ़्रेम वहाँ Vulkan renderer के फ़्रेमों की तुलना में बहुत सस्ते हैं (Animations डेमो: प्रति फ़्रेम ~9.5 ms की जगह ~1 ms ड्रॉइंग)। फिर भी चुनाव GSK_RENDERER करता है।
• Canvas rasters: हर canvas को एक बार 256 px की tiles में raster किया जाता है, जो GPU पर रखी रहती हैं। कोई एनिमेटेड वैल्यू केवल उस क्षेत्र को दोबारा बनाती है जिसे उसे पढ़ने वाले ऑपरेशन ढकते हैं, ड्रॉइंग के स्थिर हिस्से के रखे हुए पिक्सेल के ऊपर; नज़र से बाहर का canvas तब तक रुका रहता है जब तक वह स्क्रॉल होकर दिखाई न दे।
• Paths एक बार अलग रखे जाते हैं: लंबे path के बाद fillRect और fillText उसे अपनी जगह छोड़ देते हैं, जब तक उसका फिर से उपयोग न हो (400-बिंदु की एक लाइन फिर 240 bars: 0.63 ms)।

#macOS (AppKit)

एक MacBook Pro (Apple M3, 24 GB) पर उसके built-in 120 Hz ProMotion डिस्प्ले पर मापा गया, release बिल्ड, 1200 × 800 विंडो में gallery, हर रीडिंग examples/gallery/tools/perf.py (nsh test --target macos --fps, हर सेकंड एक पंक्ति) द्वारा अपने-आप ली गई; CPU पूरी प्रोसेस का है, एक कोर के प्रतिशत में, GPU उसका GPU में हिस्सा है। चरण प्रति फ़्रेम मुख्य थ्रेड के हैं: tick (display link की native animations) और canvas (ड्रॉइंग replay करना)।

#एनिमेटेड डेमो

Stocks पर एक फ़्रेम का मुख्य थ्रेड समय ~1.6 ms ticks का है, जिसमें से ~0.45 ms canvases के एनिमेटेड हिस्सों को replay करने में जाता है; हर canvas का बाकी हिस्सा Core Animation अपने थ्रेड्स पर बनाता है।

#हर पेज

Gallery का हर पेज, खुलते समय और टेस्ट द्वारा स्क्रॉल किए जाने के दौरान, उसी 1200 × 800 विंडो में। Linux की तरह, FPS वह दर है जब कुछ हिल रहा हो (बनाए गए फ़्रेमों के बीच के median अंतराल पर एक फ़्रेम); डिस्प्ले के 120 पर, किसी एनिमेशन या स्क्रॉल का हर फ़्रेम पिछले के एक रिफ़्रेश बाद आता है। Over one refresh उन फ़्रेमों का हिस्सा है जिन्होंने एक रिफ़्रेश (8.3 ms) से ज़्यादा समय लिया। आराम की स्थिति में पेज कोई फ़्रेम नहीं बनाता और 2–5% CPU उपयोग करता है। Images के GIF और WebP Core Animation में चलते हैं और वीडियो AVFoundation में, अपनी फ़्रेम दरों पर।

#मेमोरी

आराम की स्थिति में, स्टार्ट के 3 s बाद (release runners)। Footprint वह मेमोरी है जो macOS प्रोसेस के खाते में गिनता है (जो Activity Monitor दिखाता है); resident में सिस्टम की साझा लाइब्रेरियों के पेज भी जुड़ते हैं:

Gallery के टूर के दौरान प्रोसेस Canvas पेज तक 84–230 MB और Text View पेज से आगे ~350–360 MB रखती है, उस सब के साथ जो वह जानबूझकर cache करती है (decoded images, 128 MB तक सीमित; Text View पेज के दस्तावेज़) और उन frameworks के साथ जिन्हें वह पहले उपयोग पर लोड करती है (वेब व्यू के लिए WebKit); Canvas पेज के rasters, तीनों canvases स्क्रीन पर होने पर ~310 MB तक, पेज बंद होने पर चले जाते हैं।

#ऐप का आकार

nsh init द्वारा हर टेम्पलेट से बनाए गए hello world ऐप, जैसे nsh package --target macos उन्हें Apple silicon (arm64) के लिए बनाता है, link-time optimization के साथ और Linux की तरह stripped, और ऊपर के दोनों ऐप, जैसे वे Apple silicon के लिए शिप होते हैं। executable वह runner है जो .app के अंदर होता है; zip वह है जो .app को कंप्रेस करने पर मिलता है (ditto -c -k):

ये संख्याएँ किन बातों से बनती हैं:

• फ्रेम केवल बदलावों के लिए: display link तब तक टिक करता है जब तक कोई नेटिव एनिमेशन चलता है और उसके साथ ही रुक जाता है; एनिमेशन अपने पेज के साथ रुकता है (उसके view के हटने पर उसकी keyframes खत्म हो जाती हैं, और लूप अपने कॉम्पोनेंट के cleanup में रुक जाता है)।
• Canvas वहाँ ड्रॉ होते हैं जहाँ लागत सबसे कम है: जो canvas अक्सर पेंट होता है (एनिमेशन, लाइव डेटा) वह Core Animation के थ्रेड्स (drawsAsynchronously) पर ड्रॉ होता है, जिससे मुख्य थ्रेड खाली रहता है; जो कभी-कभार दोबारा बनता है वह तुरंत ड्रॉ होता है, और उस ग्राफ़िक्स मेमोरी के बिना जो asynchronous ड्रॉइंग रोकती है। एनिमेटेड वैल्यू केवल उतना क्षेत्र दोबारा ड्रॉ करती है जितना उसे पढ़ने वाले ऑपरेशन कवर करते हैं।
• Canvas के स्थिर हिस्से सुरक्षित रखे जाते हैं: जब कोई ड्रॉइंग अपरिवर्तित रहती है, तो पहले एनिमेटेड ऑपरेशन से पहले का लंबा हिस्सा एक layer के रूप में रखा जाता है; हर फ्रेम उस layer को ड्रॉ करता है और केवल बाकी एनिमेटेड हिस्से को दोहराता है, मुख्य थ्रेड पर तुरंत (Canvas पेज का gauge, clock और dot matrix: कोई GPU काम नहीं और आधी मेमोरी)।
• कंटेंट तब ड्रॉ होता है जब वह बदलता है: टेक्स्ट और canvas अपनी-अपनी layers में ड्रॉ होते हैं, और तभी दोबारा ड्रॉ होते हैं जब उनका कंटेंट या आकार बदलता है, न कि जब वे हिलते या स्क्रॉल होते हैं।

#Windows (Win32, Direct2D)

Windows 11 डेस्कटॉप (Intel Core i7-13700KF, 32 GB, NVIDIA GeForce RTX 3060 Ti) पर, 150% पर 4K 144 Hz डिस्प्ले पर मापा गया, release builds, gallery 1200 × 800 की विंडो (1800 × 1200 पिक्सेल) में, हर रीडिंग examples/gallery/tools/perf.py (nsh test --target windows --fps, प्रति सेकंड एक पंक्ति; CPU पूरी प्रोसेस का है, एक कोर के प्रतिशत में) द्वारा अपने-आप ली गई। फेज़ मुख्य थ्रेड के प्रति फ्रेम हैं: paint (Direct2D द्वारा विंडो ड्रॉ करना) और उसके भीतर canvas (ड्रॉइंग को रिकॉर्ड और रीप्ले करना)।

#एनिमेटेड डेमो

Stocks प्रति सेकंड 16–17 बार commit करता है, हर commit में engine थ्रेड पर अधिकतम 2.1 ms JS और 1.7 ms core लगता है (p95)।

#हर पेज

Gallery का हर पेज, जैसे वह खुलता है और जब टेस्ट उसे स्क्रॉल करता है, उसी 1200 × 800 की विंडो में। Linux और macOS की तरह, FPS वह दर है जब कुछ हिल रहा हो (ड्रॉ किए गए फ्रेमों के बीच के मध्यक अंतराल पर एक फ्रेम); डिस्प्ले के 144 पर, किसी एनिमेशन या स्क्रॉल का हर फ्रेम पिछले के एक रिफ्रेश बाद आता है। एक रिफ्रेश से ऊपर उन फ्रेमों का अनुपात है जिन्होंने एक रिफ्रेश (6.9 ms) से अधिक समय लिया। स्थिर पड़ा पेज कोई फ्रेम ड्रॉ नहीं करता और 0–2% CPU लेता है। Images के GIF और WebP अपनी फ्रेम दरों पर चलते हैं (यहाँ लगभग 40 FPS)। Physics, Overlays, Menus और Storage 900 × 500 की विंडो में मापे गए हैं, जहाँ उनके पास स्क्रॉल करने की जगह है।

#मेमोरी

स्थिर अवस्था में, शुरू होने के 3 s बाद (release runners, 1200 × 800 की विंडो)। Private working set वह मेमोरी है जो अकेली प्रोसेस इस्तेमाल करती है (Task Manager का Memory कॉलम); private bytes वह जो उसने commit की है; working set में सिस्टम की उन लाइब्रेरी के पेज भी जुड़ते हैं जिन्हें वह अन्य प्रोसेस के साथ साझा करती है (Direct3D, Direct2D, DirectWrite, GPU ड्राइवर):

Gallery के टूर के दौरान working set Stocks पर ~108–115 MB, Canvas पेज से ~230 MB, Text View पेज से ~320–340 MB और Web and video द्वारा WebView2 खोलने के बाद ~390–405 MB हो जाता है (इसके पेज WebView2 की अपनी प्रोसेस में चलते हैं), इसमें वह भी शामिल है जिसे वह जान-बूझकर cache करता है (डिकोड की गई images, 128 MB तक सीमित; Text View पेज के documents)।

#ऐप का आकार

nsh init द्वारा हर टेम्पलेट से बनाए गए hello world ऐप, जैसे nsh package --target windows उन्हें x86_64 के लिए बनाता है (Rust runners link-time optimization के साथ और stripped, जैसा Linux पर)। executable ऐप का <Name>.exe है; zip वह .zip है जो उसकी डायरेक्टरी के बगल में लिखा जाता है:

ये संख्याएँ किन बातों से बनती हैं:

• फ्रेम केवल बदलावों के लिए, केवल वहीं ड्रॉ होते हैं जहाँ बदलाव हुआ: compositor की गति से चलने वाला ticker तब तक चलता है जब तक कोई नेटिव एनिमेशन, ट्रांज़िशन या frame callback चलता है। एक फ्रेम उन views के क्षेत्र ड्रॉ करता है जो बदले (जहाँ वे थे और जहाँ वे हैं), उन पिक्सेल के ऊपर जो विंडो रखती है, और केवल उन्हीं को compositor के सामने प्रस्तुत करता है (Stocks: प्रति फ्रेम ~34 views)।
• Canvas अपना एनिमेटेड हिस्सा रिकॉर्ड करते हैं: एक ड्रॉइंग Direct2D command lists के रूप में रिकॉर्ड होती है, किसी भी स्केल पर vector और तीखी। जब कोई एनिमेटेड वैल्यू बदलती है, तो केवल वे ऑपरेशन दोबारा रिकॉर्ड होते हैं जो एनिमेटेड वैल्यू पढ़ने वाले पहले ऑपरेशन से आगे हैं; उससे पहले का हिस्सा रखा जाता है (Stocks: 22 धड़कती sparklines और चार्ट के लिए प्रति सेकंड ~26 ms की रिकॉर्डिंग)।
• केवल वही ड्रॉ होता है जो दिखता है: scroll view या clipping view के जो children नज़र से बाहर हैं उन्हें फ्रेम से बाहर रखा जाता है, और जिन views का अपना कोई कंटेंट नहीं है वे अपनी background और border से ज़्यादा ड्रॉ नहीं करते।

#iOS (UIKit)

iOS simulator (ऊपर वाले MacBook Pro पर एक iPhone 18 Pro Max) में मापा गया, release builds, उसी टूर के साथ (perf.py --target ios: nsh test --target ios --fps, उँगली के touches जैसे UIKit को मिलते हैं)। simulator 60 Hz पर प्रस्तुत करता है; ProMotion स्क्रीन वाले iPhone पर NSH के display links स्क्रीन के 120 Hz पर चलते हैं (जो ऐप nsh package बनाता है और development host इसे CADisableMinimumFrameDurationOnPhone के साथ माँगते हैं)। फेज़ हैं tick (नेटिव एनिमेशन), drain (engine के batches लागू करना) और scroll (scroll view के पीछे जो चलता है: lists, sticky cells, bound values)।

FPS वह दर है जब कुछ हिल रहा हो, जैसा ऊपर बताया गया: simulator के 60 पर, हर फ्रेम पिछले के एक रिफ्रेश बाद आता है। जिस पेज पर कुछ नहीं हिलता वह कोई फ्रेम ड्रॉ नहीं करता और स्थिर अवस्था में 1–2% CPU लेता है। प्रोसेस gallery के होम पेज पर 40 MB और पूरे टूर के बाद ~180 MB रखती है (जान-बूझकर cache की गई images, Text View पेज के documents)।

iPhone 17 Pro (ProMotion, 120 Hz) पर, development host और स्क्रीन पर एक डेमो के साथ, एनिमेटेड पेज हर रिफ्रेश पर ड्रॉ करते हैं:

Stocks प्रति सेकंड 20 बार commit करता है (हर 50 ms पर एक tick), हर commit में engine थ्रेड पर 1.5 ms JS और 1.4 ms core लगता है (p95 क्रमशः 2.2 और 2.0 ms), और वह थ्रेड 4–6% समय व्यस्त रहता है।

#ऐप को मापना

किसी ऐप को उसी तरह मापने के लिए, उसके टेस्ट या स्टेप --fps और -v के साथ --target linux, macos, windows या ios पर चलाएँ:

cargo build --release -p nsh-cli
python3 examples/gallery/tools/perf.py --target macos --only Stocks,Canvas   # the gallery, page by page
echo 'await app.wait(5000)' | nsh -v test App.tsx --target linux --fps        # any app