इस सप्ताह # 22900 के मजेदार अंक ने जीथूब उपयोगकर्ताओं का विशेष ध्यान आकर्षित किया है।

समस्या का एक विस्तृत विवरण दृश्य स्टूडियो कोड ( vscode ) कोड संपादक के भंडार में है। ओपन सोर्स डेवलपर जो लिस को ब्रोकोली और अन्य मुफ्त पुस्तकालयों के निर्माता के रूप में जाना जाता है। प्रोजेक्ट पेज पर, उसने देखा कि विजुअल स्टूडियो कोड प्रोसेसर के 13% कंप्यूटिंग संसाधनों का उपयोग करता है, अगर विंडो फोकस में है। इस वजह से, लैपटॉप पर बैटरी की शक्ति बर्बाद हो जाती है। कार्यक्रम के इस तरह के अजीब व्यवहार का कारण क्या हो सकता है?

जो लिस ने सुझाव दिया कि सीपीयू की गतिविधि कर्सर झिलमिलाहट का प्रतिपादन करने के साथ जुड़ी हुई है - कर्सर की स्थिति एक दो बार बदलती है, अर्थात, हर 500 एमएस (2 एफपीएस)।

समस्या को पुन: उत्पन्न करने के लिए, निम्न चरण करें:

1. Visual Studio कोड में सभी विंडो बंद करें।
2. एक नई विंडो खोलें (फ़ाइल → नई विंडो)।
3. एक खाली फ़ाइल के साथ एक नया टैब खोलें (फ़ाइल → नया टैब)। कर्सर ब्लिंक कर रहा है।
4. संसाधन मॉनिटर में, आपको कंप्यूटिंग संसाधनों की गैर-शून्य खपत (ओएस एक्स के साथ एक कमजोर लैपटॉप पर 13%, वायलैंड (आइवी ब्रिज ग्राफिक्स) के साथ एक शक्तिशाली GNOME शेल पर लगभग 5-7%) दिखाई देगी।
5. किसी अन्य एप्लिकेशन विंडो (Cmd + Tab) पर जाएं। कर्सर अब दिखाई नहीं देता है।
6. विजुअल स्टूडियो कोड का सीपीयू खपत लगभग शून्य हो गया है।

किसी को इसकी आवश्यकता है, यहाँ डेवलपर टूल में लिखने की समयरेखा है : TimelineRawData-20170321T114212.json.zip (ऊपर स्क्रीनशॉट देखें)।

यदि आप एक फ्रेम में ज़ूम करते हैं, तो आप देख सकते हैं कि 2 एफपीएस की झिलमिलाहट आवृत्ति के बावजूद, मुख्य धागा 60 एफपीएस पर कुछ काम करता है, अर्थात यह हर 16 एमएस में कुछ प्रदान करता है।



यदि आप इसे और भी करीब लाते हैं, तो आप ठोस बड़े काम को देख सकते हैं, जो कर्सर 60 फ्रेम / एस पर प्रदान करता है। ये आवधिक चक्र "अपडेट लेयर ट्री" / "पेंट" / "कम्पोज़िट लेयर्स" हैं, अर्थात, लेयर ट्री को अपडेट करना



डेवलपर इस तथ्य पर ध्यान आकर्षित करता है कि क्रोम और टेक्स्टएडिट सहित अन्य macOS सिएरा 10.12.3 अनुप्रयोगों में, कर्सर सीपीयू संसाधनों की ध्यान देने योग्य खपत के बिना फ़्लिकर करता है।

विजुअल स्टूडियो कोड एडिटर के उपयोगकर्ता प्रोग्राम में कर्सर फ्लिकर को बंद कर सकते हैं। इस मामले में, सीपीयू की खपत 0% तक कम हो जाती है। "अपडेट लेयर ट्री" / "पेंट" / "कम्पोजिट लेयर्स" लूप अभी भी काम करते हैं, लेकिन केवल हर 500 एमएस में, 16 एमएस नहीं।

"editor.cursorBlinking": "solid"

विजुअल स्टूडियो कोड में यह अजीब गड़बड़ एक क्लासिक npm ब्रेक संकेतक समस्या जैसा दिखता है । एनपीएम 3.5.2 में, प्रगति सूचक पर, सूचक के बिना ऑपरेशन लगभग 50% धीमा प्रदर्शन किया गया था।

 $ rm -r node_modules $ npm set progress=false $ time npm install npm install 19.91s user 2.66s system 71% cpu 31.667 total $ rm -r node_modules $ npm set progress=true $ time npm install npm install 33.26s user 3.19s system 74% cpu 48.733 total 

क्या कारण है

बेशक, सीपीयू की खपत जब कर्सर फ़्लिकर एक सक्रिय प्रगति संकेतक के साथ npm को धीमा करने की तुलना में पूरी तरह से अलग कारण है। यदि आप क्रोम ब्राउज़र में CSS keyframe एनीमेशन के साथ लगभग एक ही बग को देखते हैं, तो आप कर्सर के साथ समस्याओं के कारणों का अनुमान लगा सकते हैं। वहां, डेवलपर्स लिखते हैं कि जावास्क्रिप्ट में, एक टिमटिमाता कर्सर सीपीयू संसाधनों का सामान्य 1.2% खपत करता है, और सीएसएस में, किसी कारण से, 6 गुना अधिक है, अर्थात 7-8%।

कोड सही प्रतीत होता है:

 @keyframes monaco-cursor-blink { 50% { opacity: 0; } 100% { opacity: 1; } } .cursor-blink { animation: monaco-cursor-blink 1s step-start 0s infinite; } 

लेकिन समस्या यह है कि क्रोमियम इंजन इस एनीमेशन को 60 एफपीएस पर मजबूर करता है, जिससे वह हर 16 एमएस को काम करने के लिए मजबूर करता है।

तो, विज़ुअल स्टूडियो कोड संपादक स्पष्ट रूप से झिलमिलाहट कर्सर फ़ंक्शन को लागू करने के लिए सबसे तार्किक दृष्टिकोण का उपयोग करता है: यह सीएसएस कीफ़्रेम एनीमेशन के साथ step फ़ंक्शन है। और क्रोमियम में यह बग अभी तक पूरी तरह से तय नहीं हुआ है , हालांकि यह दो साल से अधिक समय से चल रहा है। इसलिए क्रोम हर 16 एमएस में एक पूर्ण रेंडरिंग चक्र चलाता है, क्योंकि यह 60 फ्रेम प्रति सेकंड के लिए होना चाहिए। शायद वर्तमान चर्चा पुराने बग पर ध्यान आकर्षित करेगी - और डेवलपर्स अंततः इस पर अपना हाथ प्राप्त करेंगे।

विजुअल स्टूडियो कोड डेवलपर्स ने स्वीकार किया कि यह फ़ंक्शन मूल रूप से जावास्क्रिप्ट में लागू किया गया था, लेकिन लगभग एक साल पहले वे सीएसएस में बदल गए। वर्तमान कार्यान्वयन में, यदि विंडो फ़ोकस से बाहर है, तो एनीमेशन निष्क्रिय है और प्रोसेसर संसाधनों की अत्यधिक खपत नहीं है, लेकिन सक्रिय विंडो के साथ वास्तव में समस्या है। डेवलपर्स का मानना ​​है कि ऐसी स्थिति में सीएसएस से जेएस में वापस जाने का कोई मतलब नहीं है।

सहकर्मियों को सलाह दी जाती है कि वे किसी कर्सर को एनिमेटेड जिफ़ के रूप में लागू करने पर भी विचार करें। आप संपादक की रंग योजना के आधार पर स्वचालित रूप से ऐसी फाइल तैयार कर सकते हैं। सच है, ज़ूम करने में कठिनाई हो सकती है: आखिरकार, ज़ूम करते समय रेखापुंज ग्राफिक्स धुंधली हो जाएगी।

लेकिन अंत में, माइक्रोसॉफ्ट के डेवलपर्स ने अभी भी कर्सर को पलक झपकाने के लिए अच्छे पुराने जेएस-विधि सेटइंटरवल में लौटने का फैसला किया - और सीपीयू की खपत तुरंत कई बार कम हो गई ।