एक समयावधि को बढ़ावा देना जहां हर कोई सॉफ़्टवेयर को तेज़ी से चलाने के लिए कोई भी विचार कर सकता है?

Question

कभी-कभी सॉफ्टवेयर प्रदर्शन के गुर एक पद्धतिगत और गहन खोज से पाए जाते हैं। कभी-कभी पागल विचारों की कोशिश करने के लिए विचलित सोच और साहस की आवश्यकता होती है। कभी-कभी एक विचार सिर्फ शुरुआत है जिसे बहुत मेहनत के साथ पालन करने की आवश्यकता है।

हम जिस सॉफ्टवेयर पर काम कर रहे हैं, उसके प्रदर्शन को बेहतर बनाने के लिए हर किसी के लिए अलग-अलग समय की कोशिश कर सकते हैं? टीम में सभी को सॉफ्टवेयर के साथ कम से कम कई महीनों का अनुभव है और यह बहुत अच्छा है।

क्या आप इस बात से सहमत हैं कि अलग-अलग सोच सॉफ्टवेयर प्रदर्शन को बेहतर बनाने में मदद करेगी? क्यों? क्यों नहीं?

क्या तकनीकें हमें एक अनुकूलन विचार को जल्दी से आज़माने में सक्षम करेंगी? क्या ट्राइ-कोड से अच्छे परिणाम प्राप्त करने के लिए तेज़ कोडिंग गति आवश्यक है?

अंत में, कितना समय "समय" को बंद करने की संभावना बनाए बिना अच्छे परिणाम सुनिश्चित करने के लिए आवंटित किया जाना चाहिए?

क्या यह साबित करने के लिए प्रयोग आवश्यक है कि "कुछ करने का तेज़ तरीका" मौजूद है? (जोड़ा गया 2011-06-07)

सम्बंधित:

• अपनी टीम के स्तर को एक चतुर तरीके से सुधारने के लिए आपकी क्या रणनीति है?
• कोड हैक कब ख़राब हो जाते हैं?

( केवल इनाम -2011/06/07 के लिए टीम का आकार 2-4 डेवलपर्स, कोई समर्पित क्यूए नहीं है। सभी कोड, इकाई परीक्षण और प्रदर्शन परीक्षण डेवलपर्स द्वारा किए गए हैं। परियोजना की प्रकृति के कारण, प्रोफाइलर परिणाम दिखाने में उपयोगी है। आनुपातिक निष्पादन समय भले ही यह एक भी अड़चन न प्रकट करे।)

Comments

जब आप कहते हैं कि प्रदर्शन में सुधार, क्या आप प्रदर्शन / बेंचमार्क परिप्रेक्ष्य से कड़ाई से बात कर रहे हैं, या क्या आप अधिक सहज यूआई, बेहतर वर्कफ़्लो इत्यादि का मतलब है, बेहतर उत्पाद?

— रिचार्ड

संभवतः प्रासंगिक टेक टॉक। यह कुछ सॉफ्टवेयर कंपनियों के इस तरह के काम करने के प्रयासों पर चर्चा करता है।

— प्रोडग्यसिम

मैं व्यक्तिगत रूप से कई प्रदर्शन परीक्षण लिखता हूं जो अस्पष्टता के बिना प्रदर्शित करता है कि किसी चीज का कार्य कितना तेज या धीमा है।

— जॉब

Answer 1

आपका सबसे अच्छा शर्त एक प्रोफाइलर के साथ हॉटस्पॉट्स की पहचान करना है और - एक टीम के रूप में - चर्चा करें कि हॉटस्पॉट्स को कैसे ठीक किया जाए।

आपको सुधार को मापने और दस्तावेज़ करने में सक्षम होना चाहिए (इसलिए यह केवल जंगली अनुमान नहीं है) और एक टीम के रूप में करना यह सुनिश्चित करता है कि लोग जानते हैं कि क्या तय किया जा रहा है और कैसे।

प्रोग्रामर ने कोडबेस में बेतहाशा हैकिंग कर विचारों को आज़माया है, जिसका मतलब है कि आपके पास जो चल रहा है उसका कोई नियंत्रण नहीं है, और यह काम करता है या नहीं।

Answer 2

प्रोग्रामर होशियार और रचनात्मक होते हैं (क्योंकि ये प्रोग्रामिंग में किसी भी अच्छे होने के लिए आवश्यक शर्तें हैं) इसलिए समस्याओं को हल करने की कोशिश करते समय उन्हें विचारों की एक विस्तृत श्रृंखला की कोशिश करने देना हमेशा अच्छा होता है। हालांकि दो चीजें हैं जो प्रदर्शन को बेहतर बनाने का प्रयास करते समय याद रखने के लिए महत्वपूर्ण हैं (मैं "प्रदर्शन" के साथ मान रहा हूं इसका मतलब है कि आप निष्पादन की गति को कम कर सकते हैं):

• एल्गोरिथ्म अनुकूलन कुछ और की तुलना में बेहतर काम करते हैं। एक तुच्छ उदाहरण के रूप में, आप जो भी अपने बुलबुले के कार्यान्वयन के लिए करते हैं, पर्याप्त संख्या के साथ क्विकॉर्ट का एक अत्यंत धीमा कार्यान्वयन अंततः तेज हो जाएगा।
• कुछ भी प्रदर्शन-संबंधी करना पूरी तरह से निरर्थक है जब तक आप परिणामों पर जो कुछ भी करते हैं (प्रोफ़ाइल) और आधार को मापते हैं।

मेरा मुख्य बिंदु यह है कि यह सुनिश्चित करना महत्वपूर्ण है कि जंगली प्रयोग की अवधि शुरू करने से पहले आप इन चीजों के बारे में सभी के साथ एक ही पृष्ठ पर हों । यह पता लगाना हमेशा शर्म की बात है कि आपके कम अनुभवी सहकर्मी ऐसी चीजों की कोशिश कर रहे थे जो कभी काम नहीं कर सकते थे (और आप उन्हें बता सकते थे कि सामने वाला)।

Answer 3

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

Answer 4

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

1. उन महत्वपूर्ण परिदृश्यों या कोड रास्तों पर ध्यान केंद्रित करने का प्रयास करें जहाँ अड़चनें संदिग्ध हैं। सामान को अनुकूलित करने में समय बर्बाद न करें जिसे अनुकूलित करने की आवश्यकता नहीं है (यदि यह टूट नहीं गया है ...)
2. समूह को छोटा रखें और उन लोगों पर ध्यान केंद्रित करें जो कोड को सबसे अच्छे से जानते हैं। फीचर के टेस्टर और प्रोग्राम मैनेजर को शामिल करना न भूलें - उनके पास महत्वपूर्ण अंतर्दृष्टि हैं और वे भाग लेने, या जानकारी इकट्ठा करने से लाभ उठा सकते हैं कि वे कैसे बेहतर परीक्षण कर सकते हैं।
3. क्षेत्र के मालिक को उच्च स्तर के वास्तुशिल्प ब्लॉक स्तर आरेख और क्षेत्र का अवलोकन करके सत्र शुरू करना। प्रमुख घटक क्या हैं और वे क्या करते हैं इसका संक्षेप में वर्णन करें। आपको आश्चर्य होगा कि कोड में खोले जाने के बाद कितनी बार ब्लॉक आरेख वास्तविकता को प्रतिबिंबित नहीं करता है। (वास्तविक उद्धरण: "मुझे नहीं पता था कि हम अभी भी उस घटक का उपयोग करते हैं। मुझे लगा कि हम उस साल पहले छुटकारा पा चुके हैं!"
4. कार्यात्मक कीड़े और साथ ही संपूर्ण मुद्दों को खोजने की अपेक्षा करें। ये अच्छी बात है। इसके अलावा, उम्मीद करें कि, कभी-कभी, आपको कुछ भी महत्वपूर्ण नहीं मिलेगा। यह एक अच्छी बात भी हो सकती है।
5. कई लंबे सत्र होने की उम्मीद है। ये कामकाजी बैठकें हैं। सहज हो जाओ, और इसके माध्यम से काम करो। जब आप सभी विस्तारित स्ट्रेच के लिए सहयोग कर सकते हैं, तो आप बहुत अधिक काम कर सकते हैं।
6. नोट्स लें, अच्छे नोट्स लें। यदि आप एक दोष ट्रैकिंग डेटाबेस का उपयोग करते हैं, तो ट्रैक रखने के लिए तुरंत मुद्दों पर विचार करें, भले ही वे कम प्राथमिकता वाले हों।

पूरी टीम के "प्रदर्शन पुश" में भाग लेने से बचें। ये आमतौर पर उन परिणामों के लिए नहीं होते हैं जो प्रबंधन उन कारणों के लिए उम्मीद करता है जो थोरबजर्न रेवन एंडरसन ने एक अन्य उत्तर में उल्लेख किया है। आपको कुछ क्षेत्रों में बहुत लाभ मिलेगा, अन्य क्षेत्रों में प्रतिगमन जहां लोग परिचित नहीं हैं, और यह भविष्यवाणी करना मुश्किल है कि आपको "आप कर रहे हैं" कहने के लिए कितना लाभ प्राप्त करना चाहिए। यह प्रबंधन के साथ एक चुनौतीपूर्ण बातचीत है।

Answer 5

यदि आपको अपने सॉफ़्टवेयर की गति में सुधार करने की आवश्यकता हो सकती है तो इसका कारण यह है कि इसमें कुछ विशेष रूप से धीमा है। यदि ऐसा नहीं है, तो अनुकूलन समय की बर्बादी है। लेकिन अगर कुछ धीमा है, तो कार्य करें।

... और कार्य करने के लिए, इस क्रम में दो चरण हैं:

1. देखें कि क्या कार्य करने वाला फ़ंक्शन कुशलता से लिखा गया है। क्या यह एक अच्छा या गरीब एल्गोरिथ्म है? क्या यह एक डेटाबेस को एक कुशल तरीके से एक्सेस कर रहा है। क्या यह 100 बार लूपिंग है जब एक बार कर सकते हैं? अक्सर, कोड का सरल निरीक्षण एक बाधा को ढूंढ सकता है और न केवल इसे ठीक कर सकता है, बल्कि एक ही समय में आपको एक बेहतर प्रोग्रामर बना सकता है।

2. नंबर 1 पर एक घंटे या उससे अधिक खर्च न करें। यदि आप एक घंटे में समस्या का पता नहीं लगा सकते हैं, तो प्रश्न में मौके का पता लगाने के लिए प्रोफाइलर का उपयोग करें। एक बार जब आप समस्या के बिंदु को जान लेते हैं, तो आप नंबर 1 पर वापस जा सकते हैं और फिर से कर सकते हैं, जो आपके द्वारा पहचाने गए कोड को बेहतर बनाने का सबसे अच्छा तरीका है।

Answer 6

सामान्य तौर पर (**) आपको प्रयोग द्वारा बेहतर प्रदर्शन नहीं मिलता है।

आप इसे प्राप्त करें

• शुरू करने के लिए एक सरल, कुशल डिजाइन बनाने का तरीका जानना। यदि आपको यह हिस्सा गलत लगता है, तो प्रयोग से बहुत फर्क नहीं पड़ेगा। उदाहरण के लिए, पता है कि कोड जनरेटर का उपयोग करते समय कैसे बताया जाए कि एक विजेता डिजाइन दृष्टिकोण है।

• यह जानना कि सॉफ्टवेयर को गतिविधियों को कैसे ट्यून करना है जो क) प्रतिशत के आधार पर महंगा है, और ख) कुछ बेहतर के साथ बदली जा सकती है। हर कोई जानता है कि आपको "एक प्रोफाइलर का उपयोग करना चाहिए", लेकिन यह पर्याप्त नहीं है।

अपने अन्य प्रश्न के उत्तर की जाँच करें।

** अपवाद कड़े हार्डवेयर-निर्भर कोड हो सकते हैं, जैसे ग्राफिक्स रेंडरिंग, प्रोसेसर पाइपलाइन या CUDA व्यवहार, या नेटवर्क या DB प्रोटोकॉल के साथ प्रयोग करना, जहां आपको इसका उपयोग करने के सर्वोत्तम तरीके से परिचित होना होगा।

जोड़ा गया: कुछ ऐसा है जो बड़े सिस्टम के कई प्रोग्रामर को आश्चर्यचकित करता है। यह है कि पूरी तरह से अच्छी तरह से निर्मित कार्यक्रमों में, बड़ी, अदृश्य प्रदर्शन समस्याएं हो सकती हैं, और प्रोफाइलर उन्हें नहीं ढूंढ सकते क्योंकि वे रूटीन के लिए स्थानीयकृत नहीं हैं। वे कार्यक्रम की सामान्य संरचना का हिस्सा हैं, भले ही कार्यक्रम बहुत अच्छी शैली में किया जा सकता है।

बस एक ठोस उदाहरण देने के लिए, यहां एक स्रोत कोड (सी ++ में) के साथ एक कार्यक्रम है जो नौकरी करता है। यह मेरे द्वारा काम किए गए एक वास्तविक सी कार्यक्रम से आसुत है।

यह वही करता है जो इसे करने का इरादा था, लेकिन इसके समय का कौन सा अंश वास्तव में आवश्यक नहीं है? इसे कितनी गति दी जा सकती थी?

ठीक है, कार्यक्रम के पहले संस्करण में, कुछ पूरी तरह से उचित दिखने वाला और नॉनोकॉकल (एक प्रोफ़ाइलर के लिए अदृश्य) समय का 33.3% ले रहा था। जब इसे प्रतिस्थापित किया गया था, तो उस समय को बचाया गया था, और यह कार्यक्रम का दूसरा संस्करण था।

कार्यक्रम के दूसरे संस्करण में, कुछ और (किसी भी प्रोफाइलर के लिए अदृश्य) जिसे हटाया जा सकता था, 16.7% समय ले रहा था। इसे हटाकर संस्करण 3 का नेतृत्व किया।

संस्करण 3 में, 13% हटा दिया गया था। जो बचा था, उसमें से 66% हटा दिया गया था। उसके बाद जो बचा था, उसमें से ६१% हटा दिया गया था!

फिर आखिरकार, उसके बाद जो बचा था, उसमें से 98% को हटा दिया गया था!

तो बड़ी तस्वीर क्या है? मूल कार्यक्रम द्वारा खर्च किए गए प्रत्येक 1000 चक्रों में से कितने हटाए गए थे? 998!

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

Comments

अपने उत्तर को अधिक स्व-स्थायी बनाने के लिए, आप इस बात पर विस्तार से जानना चाह सकते हैं कि विभिन्न संस्करणों में जिन चीजों को प्रतिस्थापित किया गया था, वे वास्तव में क्या थीं।

@ Thorbjørn: यह परियोजना में सभी है, और पीडीएफ स्लाइड शो में संक्षेप में कहा गया है, और जैसा कि मैंने कहा, हर कार्यक्रम अलग है। केवल एक ही विधि है।

— माइक डनलवे