आधुनिक कंप्यूटिंग के दिनों में, 'विशिष्ट व्यवसाय ऐप्स' में - प्रदर्शन क्यों मायने रखता है? [बन्द है]

Question

यह आप में से कुछ के लिए एक अजीब सवाल की तरह लग सकता है।

मैं एक शौक़ीन जावा प्रोग्रामर हूँ। मैंने कई गेम विकसित किए हैं, एक एआई प्रोग्राम जो संगीत बनाता है, पेंटिंग के लिए एक और प्रोग्राम और इसी तरह का सामान। यह आपको बताना है कि मुझे प्रोग्रामिंग में अनुभव है, लेकिन व्यावसायिक अनुप्रयोगों के पेशेवर विकास में नहीं।

मुझे इस साइट पर प्रदर्शन के बारे में बहुत सारी बातें दिखती हैं। लोग अक्सर बहस करते हैं कि किसी कार्य को करने के लिए C # में सबसे कुशल एल्गोरिदम क्या होगा, या पायथन धीमा क्यों है और जावा तेज है आदि।

जो मैं समझने की कोशिश कर रहा हूं वह यह है: यह बात क्यों है?

कंप्यूटिंग के विशिष्ट क्षेत्र हैं जहां मैं देखता हूं कि प्रदर्शन क्यों मायने रखता है: खेल, जहां दसियों हजारों संगणनाएं निरंतर-अपडेट लूप में हर सेकंड हो रही हैं, या निम्न स्तर की प्रणालियां जो अन्य कार्यक्रमों पर निर्भर करती हैं, जैसे कि ओएस और वीएम, आदि।

लेकिन सामान्य, विशिष्ट उच्च-स्तरीय व्यावसायिक ऐप के लिए, प्रदर्शन क्यों मायने रखता है?

मैं समझ सकता हूं कि दशकों पहले यह क्यों मायने रखता था। कंप्यूटर बहुत धीमे थे और उनकी मेमोरी बहुत कम थी, इसलिए आपको इन बातों पर ध्यान से सोचना चाहिए।

लेकिन आज, हमारे पास स्पेयर करने के लिए इतनी मेमोरी है और कंप्यूटर बहुत तेज़ हैं: क्या यह वास्तव में मायने रखता है अगर एक विशेष जावा एल्गोरिथ्म हे (एन ^ 2)? क्या यह वास्तव में इस विशिष्ट व्यवसाय ऐप के अंतिम उपयोगकर्ताओं के लिए एक अंतर होगा?

जब आप किसी विशिष्ट व्यवसाय ऐप में एक GUI बटन दबाते हैं, और पर्दे के पीछे यह एक हे (n ^ 2) एल्गोरिदम, आधुनिक कंप्यूटिंग के इन दिनों में - क्या आप वास्तव में अक्षमता महसूस करते हैं?

मेरा प्रश्न दो में विभाजित है:

1. व्यवहार में, आज एक सामान्य सामान्य व्यावसायिक कार्यक्रम में प्रदर्शन मायने रखता है?
2. यदि ऐसा होता है, तो कृपया मुझे इस तरह के एप्लिकेशन में वास्तविक दुनिया के उदाहरण दें, जहां प्रदर्शन और अनुकूलन महत्वपूर्ण हैं।

Comments

संबंधित: इतने सारे डेवलपर्स प्रदर्शन, पठनीयता और रखरखाव पर विश्वास क्यों नहीं कर सकते हैं?

— पेटर टॉर्क

खराब होने पर प्रदर्शन मायने रखता है।

— माइक डनलैवी

Answer 1

आप सही हैं, व्यावसायिक कार्यक्रमों में प्रदर्शन वास्तव में एक महत्वपूर्ण विषय नहीं है जिस तरह से अधिकांश प्रोग्रामर द्वारा चर्चा की जाती है । आमतौर पर, प्रदर्शन-संबंधी चर्चाएँ जो मैं प्रोग्रामरों से सुनता हूं, उनमें कई मुद्दे होते हैं:

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

• वे अक्सर सट्टा करते हैं । मुझे यह देखकर खुशी हुई है कि स्टैक ओवरफ्लो और प्रोग्रामर्स पर। ईई , प्रोफाइलिंग का उल्लेख अक्सर किया जाता है जब प्रश्न प्रदर्शन से संबंधित होता है, लेकिन जब मैं दो प्रोग्रामर देखता हूं तो मुझे निराशा नहीं होती है, जो यह नहीं जानते हैं कि प्रदर्शन के बारे में क्या चर्चा कर रहे हैं- संबंधित परिवर्तन उन्हें अपने कोड में करना चाहिए। उनका मानना ​​है कि परिवर्तन सब कुछ तेज कर देगा, लेकिन व्यावहारिक रूप से हर बार, इसका या तो कोई प्रभाव नहीं दिखाई देगा या चीजों को धीमा कर देगा, जबकि एक प्रोफाइलर ने उन्हें कोड के दूसरे भाग में इंगित किया होगा जो आसानी से अनुकूलित किया जा सकता है और जो 80% बर्बाद करता है समय की।

• वे केवल तकनीकी पहलुओं पर केंद्रित हैं। उपयोगकर्ता-उन्मुख अनुप्रयोगों का प्रदर्शन भावना के बारे में है: क्या यह तेज और उत्तरदायी लगता है, या क्या यह धीमा और भद्दा लगता है? इस संदर्भ में, प्रदर्शन समस्याओं को आमतौर पर उपयोगकर्ता अनुभव डिजाइनरों द्वारा बहुत बेहतर तरीके से हल किया जाता है: एक साधारण एनिमेटेड संक्रमण अक्सर एक ऐप के बीच अंतर हो सकता है जो बहुत धीमा लगता है और जिस ऐप को उत्तरदायी लगता है, जबकि दोनों 600 एमएस खर्च करते हैं। ऑपरेशन कर रहा है।

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

एक प्रोग्रामर के रूप में अपने करियर के दौरान, मैं अपने ग्राहकों के एक समूह के लिए सॉफ्टवेयर के एक टुकड़े पर काम कर रहा था। मुझे यकीन था कि यह सॉफ्टवेयर अगली महान चीज है जो दुनिया में खुशी लाएगी, इसलिए मैं स्पष्ट रूप से प्रदर्शन से चिंतित था।

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

कभी-कभी, मैंने रातें बदल कर बिताईं, जो मुझे यकीन था, एक धीमी ऐप जिसे कोई नहीं चाहता, के बीच अंतर किया गया, और एक तेज़ हर कोई डाउनलोड और उपयोग करना चाहता है। तथ्य यह है कि दो वास्तविक ग्राहक जो इस ऐप के लिए रुचि रखते थे, ने वास्तविक सुविधाओं का अनुरोध किया था जो मुझे परेशान नहीं कर रहे थे: "यदि ऐप धीमा है, तो कौन एक सुविधा चाहता है?" - मैंने सोचा।

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

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

यह कहा जा रहा है, सामान्य रूप से प्रदर्शन महत्वपूर्ण है :

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

• व्यवसाय एप्लिकेशन में, लेकिन कई मामलों में एक आवेदन जो कर रहे हैं लगता है और है धीमी उपयोगकर्ताओं द्वारा नफरत की जाएगी। आप नहीं चाहते कि, आपकी चिंताओं पर प्रदर्शन हो।

Comments

महान उत्तर, विशेष रूप से व्यर्थ की परिपूर्णता चर्चा और व्यर्थ अनुकूलन पर ध्यान केंद्रित करने के कारण।

— डॉक्टर ब्राउन

a simple animated transition may often be the difference between an app which feels terribly slow and the app which feels responsive- हालांकि ये निश्चित रूप से संयम से इस्तेमाल किया जाना चाहिए, उन ऐप्स के लिए जो हर दिन एनिमेशन और बदलावों को मिटाते हैं, अगर वे दैनिक आधार पर उन बदलावों को घूर रहे हों, तो निराशा हो सकती है!

— कॉस्मिक ओस्सिफ्रेज

आपकी बोली का स्रोत क्या है?

— एडम जॉन्स

@ अदमजोन: कोई स्रोत नहीं। यह मेरे अपने लेखों के ड्राफ्ट से उद्धृत किया गया है जो अभी तक मेरे ब्लॉग पर प्रकाशित नहीं हुए हैं।

— आर्सेनी मूरज़ेंको

@ मेनमा ओह कमाल। मुझे आपकी बात से बहुत कम चित्रण में मजा आया।

— एडम जॉन्स

Answer 2

हाँ। हाँ यह करता है। रन-टाइम स्पीड एकमात्र चिंता नहीं है जो आपको होनी चाहिए, और यह 1982 की तरह दबाने वाली नहीं है, या जैसा कि यह अभी भी कम-शक्ति वाले एम्बेडेड सिस्टम पर है, लेकिन यह हमेशा एक चिंता का विषय है, और यह महत्वपूर्ण है कि आप समझें ऐसा क्यों है।

एक के लिए, आपके द्वारा उल्लिखित स्पर्शोन्मुख जटिलता एक प्रोग्राम के व्यवहार का वर्णन करती है क्योंकि इसका इनपुट आकार बढ़ता है । एक गैर-रेखीय कार्यक्रम जो 10 वस्तुओं से संबंधित होता है, शानदार काम करने के साथ दूर हो सकता है, लेकिन यह आपको काटेगा जब एक दिन आपको 1000 से निपटना होगा, क्योंकि यह सिर्फ धीमा नहीं लगेगा, लेकिन बहुत, बहुत धीमा। और आपको पता नहीं है (व्यापक विश्लेषण और बेंचमार्किंग के बिना) कि क्या यह बिंदु १०० वस्तुओं पर होगा, १००० वस्तुओं पर, या तब तक नहीं जब तक कि आप १,००,००० आइटम नहीं लेंगे। यह विश्वास करना कठिन हो सकता है, लेकिन निश्चित रूप से सबसे अच्छा एल्गोरिथ्म का चयन करना वास्तव में हर दिनचर्या के लिए इस बिंदु का अनुमान लगाने और इस अनुमान के आधार पर अपने कार्यान्वयन को चुनने की तुलना में बहुत आसान है।

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

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

Comments

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

— joshin4colours

Answer 3

हाँ यह करता है!

चूंकि आपने उदाहरणों के लिए पूछा है, हर दिन कई परिस्थितियां दिमाग में आती हैं:

1. बिग-डेटा को हैंडल करना : कई बिजनेस-एप्लिकेशन डेटा-बेस द्वारा समर्थित होते हैं और कई उदाहरणों में ये डेटा-बेस डेटा के साथ बह जाते हैं। और चूंकि ड्राइव-स्पेस सस्ता है, रिकॉर्ड किए गए और संग्रहीत डेटा की मात्रा पागल है। पिछले सप्ताह एक ग्राहक ने शिकायत की, कि उसका आवेदन बहुत धीमा है, जब बस कुछ औसत संख्या (कुछ मिलियन पंक्तियों पर प्रश्न ...) प्रदर्शित कर रहा है - इसके अलावा हर रोज उपयोग में हम बैच-डेटा रूपांतरण और कई की लीग में रनटाइम के साथ गणना करते हैं घंटे। पिछले साल एक एल्गोरिथम ऑप्टिमाइज़ेशन ने एक बैच के प्रोसेस टाइम को 8 से 4 घंटे तक नीचे ला दिया था, अब यह दिन की शिफ्ट से नहीं टकराता है!

2. जवाबदेही : प्रयोज्य अध्ययन किए गए हैं (यदि मेरे पास समय है तो मैं ux.se ... पर प्रासंगिक प्रश्नों के लिंक जोड़ूंगा) कि उपयोगकर्ता संतुष्टि जवाबदेही से संबंधित है। 200ms बनाम 400ms के प्रतिक्रिया-समय में अंतर आसानी से आपके ग्राहकों का एक बड़ा प्रतिशत आपके प्रतिद्वंद्वियों के लिए आपको छोड़कर जा सकता है।

3. एंबेडेड सिस्टम : कंप्यूटर तेज नहीं हो रहे हैं, वे धीमे और छोटे हो रहे हैं ^ _ ^ मोबाइल विकास का अनुप्रयोग विकास पर भारी प्रभाव पड़ता है। यकीन है कि हम आधुनिक डेस्कटॉप कंप्यूटरों पर जेली बीन्स की तरह मेमोरी और सीपीयू चक्रों के आसपास फेंक सकते हैं, लेकिन अब आपका बॉस आपसे एक फ्रिकिन घड़ी या सिम-कार्ड पर नींद-विश्लेषण एल्गोरिदम को लागू करने के लिए कहता है ...

Answer 4

व्यवहार में, आज एक सामान्य सामान्य व्यावसायिक कार्यक्रम में प्रदर्शन मायने रखता है?

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

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

Answer 5

आधुनिक व्यावसायिक अनुप्रयोगों में, प्रदर्शन समस्याएं सीपीयू या मेमोरी की कमी के रूप में नहीं हैं। लेकिन वे नेटवर्क विलंबता के रूप में हैं, I / O प्रदर्शन और सार उन सभी को छिपाते हैं। यह सब इस बात पर निर्भर करता है कि डेवलपर्स कितने अच्छे डिज़ाइन और कितने अनुभवी हैं। यहां तक ​​कि साधारण सीआरयूडी एप्लिकेशन को एक पड़ाव तक क्रॉल किया जा सकता है यदि वह क्वेरी चलाने के बजाय डीबी एक पंक्ति से खींच रहा हो (जिसे एन + 1 समस्या भी कहा जाता है)।

समस्या यह है कि अच्छा डिज़ाइन और अनुभवी डेवलपर्स होना महंगा है। और यह आमतौर पर वास्तविक प्रदर्शन अनुकूलन में निवेश करने की तुलना में परेशान उपयोगकर्ताओं के लिए बहुत सस्ता है। कुछ मामले हैं, जहां ग्राहकों को उच्च प्रदर्शन (उदाहरण के लिए वेब ब्राउज़र) की आवश्यकता होगी, लेकिन वे शायद ही कभी आम व्यावसायिक अनुप्रयोगों पर लागू होते हैं।

Answer 6

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

Comments

वास्तव में समस्या में अधिक हार्डवेयर फेंकने से अधिकांश स्थिर कारक बेहतर तरीके से हल हो जाते हैं, क्योंकि आमतौर पर अधिक हार्डवेयर चीज को अनुकूलित करने की तुलना में अधिक समय सस्ता होता है। समस्या खराब स्पर्शोन्मुख (स्केलिंग) व्यवहार है, क्योंकि अधिक हार्डवेयर फेंकने से बहुत मदद नहीं मिलेगी।

— Jan Hudec

आप केवल एक बार ऑप्टिमाइज़ करते हैं, लेकिन आप हर महीने इलेक्ट्रिक्ल बिल का भुगतान करते हैं।

— Jaydee

@JHHudec: मैं यह नहीं देखता कि आप वास्तव में यह कैसे कह सकते हैं कि एक सीधे चेहरे के साथ जब आप वर्तमान में (हमारी प्रिय स्टैक एक्सचेंज) वेबसाइट पर हैं, तो दुनिया भर में एक महीने में 560M पृष्ठ के दृश्य मात्र 25 सर्वरों पर चलते हैं ।

— मेहरदाद

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

— Jan Hudec

... और निष्पक्ष होने के लिए, डेटाबेस, जो कि अधिकांश ग्रंट काम कर रहा है, लिखा गया था और तेजी से जाने के लिए अनुकूलित किया गया था।

— ब्लरफ्ल

Answer 7

यह निश्चित रूप से बहुत मायने रखता है।

मुख्य मुद्दा उपयोगकर्ता के लिए परेशान होने के बारे में भी नहीं है, जैसे कि GUI तत्व दो बार या तीन बार (जो कि एकीकृत ग्राफिक्स पर कोई फर्क नहीं पड़ता है) अतिव्यापी होने का अनुभव कर रहा है या केवल इसलिए कि कार्यक्रम को करने में इतना समय लगता है ... जो भी हो! करता है (ज्यादातर सामान रहित)। हालाँकि, यह भी एक मुद्दा है।

तीन महत्वपूर्ण गलत धारणाएं हैं:

1. अधिकांश विशिष्ट व्यवसाय कंप्यूटर "इतने अधिक शक्तिशाली" नहीं हैं । ठेठ व्यापार कंप्यूटर है नहीं एक किक गधा ग्राफिक्स कार्ड और राम के 16GB के साथ एक 8 कोर i7। यह एक मध्यवर्गीय मोबाइल प्रोसेसर, एकीकृत ग्राफिक्स, मुख्य मेमोरी के 2GB (यदि आप भाग्यशाली हैं तो 4GB), 5400RPM डिस्क, और विभिन्न प्रकार के रियलटाइम एंटीवायरस और नीति-प्रवर्तन के साथ विंडोज के एक एंटरप्राइज़ संस्करण के साथ एक नोटबुक है। पृष्ठभूमि। या, अधिकांश सलाहकारों के लिए, "कंप्यूटर" केवल iPhone है ...
2. अधिकांश "विशिष्ट व्यवसाय उपयोगकर्ता" तकनीशियन नहीं हैं, वे 10-12 क्रॉस-रेफ़रिंग टैब, 150 कॉलम और 30,000 पंक्तियों के साथ एक स्प्रेडशीट बनाने के निहितार्थ को नहीं समझते हैं (ये आंकड़े उतने अवास्तविक नहीं हैं जितना आप मान सकते हैं!) और वे जानना भी नहीं चाहते। वे बस कर देंगे।
3. एक दूसरी खोई लागत नहीं है एक स्पष्ट रूप से गलत धारणा है।

मेरी पत्नी ऐसे "विशिष्ट व्यावसायिक वातावरण" के ऊपरी छोर पर काम करती है। कंप्यूटर कि वह लागत का उपयोग कर रहा है, उसके काम के समय के 3.5 घंटे के बारे में अधिक है। माइक्रोसॉफ्ट आउटलुक को शुरू करना - एक अच्छे दिन पर - लगभग 3 मिनट तैयार होने तक (6-8 मिनट क्वार्टर-एंड पर जब सर्वर भारी लोड के अधीन हैं)। उन 30k-row-स्प्रैडशीट में से कुछ का उल्लेख मूल्य अपडेट करने में 2-3 सेकंड के लिए होता है, जिसके दौरान कंप्यूटर "फ्रोजन" होता है (यह उल्लेख करने के लिए नहीं कि एक्सेल को शुरू करने और उन्हें पहली बार खोलने में कितना समय लगता है!)। डेस्कटॉप साझा करते समय यह और भी बदतर है। मुझे SAP पर भी मत जाओ।
यह निश्चित रूप से मायने रखता है कि क्या प्रत्येक सौ से सौ लोग प्रत्येक दिन काम करने के इंतजार में 20-25 मिनट खो देते हैं। वे लाखों खो गए हैंआप उन्हें खोने के बजाय, लाभांश के रूप में भुगतान कर सकते हैं (या उच्च मजदूरी का भुगतान कर सकते हैं)।
निश्चित रूप से, अधिकांश कर्मचारी पेस्केल के निचले छोर पर हैं, लेकिन कम समय पर भी पैसा है ।

Answer 8

मैं समझ सकता हूं कि दशकों पहले यह क्यों मायने रखता था। कंप्यूटर बहुत धीमे थे और उनकी मेमोरी बहुत कम थी, इसलिए आपको इन बातों पर ध्यान से सोचना चाहिए।

आप कम से कम कितनी जल्दी N ^ 2 बढ़ता है कम करने लगते हैं। कहते हैं कि हमारे पास एक कंप्यूटर है और हमारा N ^ 2 एल्गोरिथ्म 10 सेकंड लेता है जब N = 10. समय बीत जाता है अब हमारे पास एक नया प्रोसेसर है जो हमारे मूल से 6 गुना तेज है इसलिए हमारी 10 सेकंड की गणना अब दो सेकंड से कम है। N कितना बड़ा हो सकता है और अभी भी उस मूल 10 सेकंड के रन टाइम में फिट हो सकता है? अब हम 24 वस्तुओं को संभाल सकते हैं, जो दो बार से थोड़ा अधिक है। हमारी प्रणाली को कितनी तेजी से 10 गुना संभालना होगा, क्योंकि कितनी वस्तुएं हैं? वैसे इसे 100 गुना तेज होना होगा। डेटा बहुत तेजी से बढ़ता है और एन ^ 2 एल्गोरिदम के लिए कंप्यूटर हार्डवेयर प्रगति को मिटा देता है।

Comments

एक अन्य उदाहरण: यदि एक तत्व को संसाधित करने में 30 CPU चक्र या 10ns लगते हैं (जो कि काफी सस्ता है), एल्गोरिथम पहले से ही एक पूर्ण सेकंड लेगा यदि आपके पास केवल 10000 तत्व हैं। कई संदर्भों में 10000 तत्व ज्यादा नहीं हैं।

— कोडइन्चोस

Answer 9

आप विश्वास नहीं करेंगे कि हम काम पर उपयोग करने वाले तीसरे पक्ष के व्यावसायिक कार्यक्रमों में से कई हैं, और उनमें से कई मेरे व्यक्तिगत मानकों की तुलना में उपयोग करने के लिए हास्यास्पद रूप से धीमा हैं। यदि प्रोग्राम कुछ ऐसे होते हैं जो मैं घर पर उपयोग करता हूं, तो मैं उन्हें बहुत पहले एक विकल्प के साथ बदल देता।

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

एक उदाहरण घटना प्रबंधन है जहां काम को 15 मिनट के अंतराल (सर्विस डेस्क) में मापा जाता है। यदि प्रोग्राम 15 मिनट से अधिक समय के लिए एक टिकट को धक्का देने के लिए पर्याप्त धीमा है (वास्तविक कार्य), तो यह प्रक्रिया को काफी धीमा कर देगा। जब भी उपयोगकर्ता कोई क्रिया करता है, तो इसका एक कारण एक धीमी डेटाबेस एक्सेस हो सकता है, जो "थोड़ी देर के लिए प्रतीक्षा करता है" (रिज़ॉल्यूशन विवरण, अद्यतन जानकारी, या समान भरें)। मैं कल्पना कर सकता हूं कि ऐसे मामले हैं जहां धीमी गति से चलने वाले कार्यक्रम और भी महत्वपूर्ण चीजों को प्रभावित कर सकते हैं, जैसे कि अस्पताल के मरीज को तत्काल विषाक्तता के मामलों पर जानकारी - शायद दवा की एलर्जी या ऐसा?

Answer 10

अन्य जवाबों में से कई विषय काफी अच्छी तरह से कवर करते हैं, इसलिए मैं उन्हें कारणों और तर्कसंगतताओं के बारे में बताता हूं। इसके बजाय, मैं यह दिखाने के लिए एक वास्तविक जीवन का उदाहरण देना चाहता हूं कि एल्गोरिथम की पसंद के वास्तविक निहितार्थ कैसे हो सकते हैं।

http://windowsitpro.com/windows-xp/svchost-and-windows-update-windows-xp-still-problem

लिंक किए गए लेख विंडोज एक्सपी अपडेट की गणना करने के लिए एल्गोरिथ्म में एक बग का वर्णन करता है। Windows XP के अधिकांश जीवन के लिए, अपडेट एल्गोरिथ्म ने ठीक काम किया। एल्गोरिथ्म यह गणना करता है कि क्या पैच को नए पैच से अलग किया गया है, और इस प्रकार स्थापित करने की आवश्यकता नहीं है। अंत में, हालांकि, सुव्यवस्थित अपडेट की सूची बहुत लंबी हो गई *।

अद्यतन एल्गोरिथ्म घातीय था, जहां प्रत्येक नए अपडेट को पिछले एक ( ) के रूप में गणना करने के लिए दो बार लिया गया । जब सूचियां 40 अपडेट रेंज (* लंबी ) में उठती हैं, तो अद्यतनों की जांच के लिए, पूर्ण क्षमता पर चलने में 15 मिनट तक का समय लगता है । यह प्रभावी रूप से अद्यतन के दौरान कई XP मशीनों को बंद कर दिया। इससे भी बुरी बात यह है कि जब कोई अपडेट को स्थापित करने के लिए जाएगा, तो एल्गोरिथ्म फिर से चलेगा , एक और 15 मिनट लगेंगे। चूंकि कई मशीनों में ऑटोमैटिक अपडेट सेट था, इसलिए यह मशीनों को हर बूट पर 15 मिनट तक लॉक कर सकता है, और संभवतः एक निश्चित आवधिकता पर फिर से।O(n) = 2n

Microsoft ने इस समस्या को दूर करने के लिए अल्पकालिक हैक (अद्यतन सूची से आइटम हटा) और दीर्घकालिक फिक्स दोनों का उपयोग किया। यह महत्वपूर्ण था क्योंकि विंडोज के नवीनतम संस्करण भी एक ही एल्गोरिथ्म का उपयोग कर रहे थे, और एक दिन उसी समस्या का सामना कर सकते हैं।

यहां हम देख सकते हैं कि एल्गोरिथम की पसंद के वास्तविक निहितार्थ थे। गलत एल्गोरिदम, जबकि उत्पाद के अधिकांश जीवन के लिए ठीक है, फिर भी सड़क पर नकारात्मक प्रभाव पड़ सकता है।

Answer 11

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

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

Answer 12

यह बहुत हद तक इस बात पर निर्भर करता है कि आप "अच्छे प्रदर्शन" को कैसे परिभाषित करते हैं। आपके एल्गोरिदम को हमेशा सर्वोत्तम संभव जटिलता का उपयोग करना चाहिए। अपने औसत पिंजरे को गति देने के लिए खामियों का दुरुपयोग करें। एक संवादात्मक कार्यक्रम में जहाँ भी संभव हो बफर और प्रीलोड / प्रीकम्पाइल।

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

उस बिंदु पर जावा / हास्केल / सी ++ का उपयोग करना केवल एक और डिजाइन निर्णय बन जाता है। आपके GPU पर OpenCL के माध्यम से नंबर क्रंच किया जा सकता है। उपयोगकर्ता इंटरफ़ेस को लगातार समय एल्गोरिदम की आवश्यकता होती है और वे अच्छे होते हैं। 20% बेहतर कैश उपयोग के लिए अपनी कक्षाओं को संरेखित करने की तुलना में आउटपुट और मॉड्यूलरिटी अधिक महत्वपूर्ण है। मल्टीथ्रेडिंग महत्वपूर्ण हो जाता है, क्योंकि लोग तेज़ ऐप नहीं चाहते हैं, वे एक उत्तरदायी चाहते हैं। जो महत्वपूर्ण नहीं है वह यह है कि आपका ऐप लगातार 10% धीमा हो सकता है। यहां तक ​​कि 50% ठीक है (लेकिन लोग सवाल पूछना शुरू कर देते हैं)। शुद्धता, जवाबदेही और प्रतिरूपकता पर ध्यान दें।

मुझे हास्केल में प्रोग्रामिंग करना पसंद है या कम से कम एक कार्यात्मक रूप में (यहां तक ​​कि C ++ में)। अपने पूरे कार्यक्रम के लिए आसानी से परीक्षण लिखने में सक्षम होना बैच की नौकरियों में थोड़ा तेज़ होने की तुलना में अधिक महत्वपूर्ण है।

Answer 13

काफी सरल: लागत

मेरे पिछले नियोक्ता के पास एक सीखने की प्रबंधन प्रणाली थी जिसे एक सास मॉडल के रूप में भौतिक सर्वरों पर होस्ट किया गया था। JVM के ढेर को पुरानी मशीनों के लिए 2 GB और नई मशीनों के लिए 3 GB में कॉन्फ़िगर किया गया था और हमने प्रति मशीन कई इंस्टेंसेस चलाए। आपको लगता है कि यह पर्याप्त होगा।

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

परेशानी यह है कि हमारे पास काम करने के लिए 2 जीबी था। तो स्पष्ट समाधान के लिए अक्सर पढ़ा डेटा के सभी कैशिंग शुरू है। तब हमारे पास स्मृति मुद्दे थे, जो मेरे बोर्ड पर आने से ठीक पहले शुरू हुए।

इस पर विचार के 2 स्कूल थे:

1. आम तौर पर मेमोरी और हार्डवेयर इन दिनों सस्ते हैं। बस अधिक रैम खरीदें ताकि आप अधिक कैश कर सकें।
2. एक लर्निंग मैनेजमेंट सिस्टम को 3+ जीबी रैम की आवश्यकता क्यों है? सभी इसे SQL क्वेरीज़ जारी करते हैं, पाठ्यक्रमों को लॉन्च करने के लिए रीडायरेक्ट भेजते हैं, और पाठ्यक्रमों के माध्यम से छात्रों की प्रगति का मूल्यांकन करते हैं।

दूसरा तर्क जीत गया और मैंने एक साल तक हमारी स्मृति के उपयोग को देखते हुए बिताया।

मेरा वर्तमान नियोक्ता एक लर्निंग मैनेजमेंट सिस्टम भी होस्ट करता है, लेकिन इसे थोड़ा अलग तरीके से होस्ट करता है। स्केलेबिलिटी इतनी खराब है कि एक एकल इंस्टॉलेशन (4 लोड संतुलित वर्चुअल सर्वर पर विभाजित) केवल 80 ग्राहकों को ही संभाल सकता है। हमारे कुछ बड़े ग्राहकों को भी सर्वर का अपना सेट मिलता है। इसको ले जाने वाले अधिकांश मुद्दे प्रदर्शन की समस्याएँ हैं, जैसे कि SQL क्वेरीज़ जो सभी सीपीयू साइकिल, मेमोरी लीक, निरर्थक कोड को हॉग करती हैं जो एक ही चीज़ को कई बार करती हैं। हमारे पास एक इन-हाउस ऐप भी बनाया गया है जिसका एकमात्र उद्देश्य सर्वरों को पुनरारंभ करना है जब वे खराब प्रदर्शन नहीं कर रहे हैं। एक कर्मचारी है जो उस टूल (अन्य जिम्मेदारियों के साथ) को बनाए रखता है।

उन्होंने सोचा था कि मैंने ऊपर उल्लेख किया है कि पहले स्कूल की सदस्यता ली: इस पर अधिक हार्डवेयर फेंक दें क्योंकि हार्डवेयर की लागत डेवलपर वेतन से सस्ता है।

यह अपेक्षा के अनुरूप आर्थिक रूप से कारगर नहीं हुआ। सर्वर को संभालने के लिए हार्डवेयर, सॉफ्टवेयर लाइसेंसिंग और सपोर्ट कर्मियों के बीच, हमने हर साल लाखों खर्च किए, ताकि डेवलपर समय व्यतीत करने वाले कोड से बचें।

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

टी एल; डॉ

यदि आप गहन लागत / लाभ विश्लेषण करते हैं, तो आप देखेंगे कि कोड को ठीक करना सस्ता है। एक ज्ञात प्रदर्शन समस्या जिसे आप अनदेखा करते हैं वह तकनीकी ऋण में बदल जाती है ।

Comments

प्रत्येक लागत / लाभ विश्लेषण का परिणाम "कोड को ठीक करना" नहीं होगा। प्रोग्रामर बहुत महंगे हैं, और यदि आप एक प्रोग्रामर की लागत से कम में रैम जोड़ सकते हैं और फिर भी समस्या को ठीक कर सकते हैं ...

— रॉबर्ट हार्वे

यह अच्छा है कि क्लाउड-होस्टिंग स्थितियों में इतना आगे बढ़ने के साथ, आप देख सकते हैं कि आप वास्तव में बिजली के लिए कितना भुगतान कर रहे हैं। उदाहरण के लिए, हम डेटाबेस के लिए Amazon RDS का उपयोग करते हैं। सबसे बड़े और दूसरे सबसे बड़े उदाहरण के बीच का अंतर लगभग है। $ 3500 प्रति वर्ष। यह एक संख्या है जिसे आप देख सकते हैं और यह निर्धारित कर सकते हैं कि अनुकूलन के लिए प्रोग्रामर के बहुत समय के लायक है या नहीं।

— कार्सन 63000

@ रोबर्टहवे सच है, मुझे इससे बाहर नहीं होना चाहिए था। मेरे कहने का मतलब यह था कि निरपेक्ष "हार्डवेयर देव समय से सस्ता है" बिल्कुल सच नहीं है, लेकिन आप सही हैं, यह कभी-कभी सच हो सकता है।

— ब्रैंडन

Answer 14

मैंने आपके प्रश्न को इस तरह समझा: अच्छे-अच्छे प्रदर्शनों को प्राप्त करने के लिए (अर्थात उपयोगकर्ता खुश हैं और मेरा बैकएंड खराब नहीं होता है), क्या मुझे एल्गोरिथम जटिलता पर सिद्धांत को समझने की आवश्यकता है?

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

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

आजकल ये अपवाद अधिक से अधिक आम होते जा रहे हैं और जब आप उन लोगों की तलाश करते हैं तो बाजार बहुत शुष्क होता है। तो: हाँ, आप बिना कंप्यूटर विज्ञान की पृष्ठभूमि के सफल हो सकते हैं, लेकिन आप कुछ के साथ और भी अधिक होंगे।

Answer 15

अन्य उत्तरदाताओं ने अधिकांश मूल बिंदुओं को कवर किया है, लेकिन उन कार्यों के लिए जो कि समानांतर, अक्षम सॉफ्टवेयर हो सकते हैं, अधिक सर्वर के रूप में हार्डवेयर लागत में वृद्धि करते हैं, जो अधिक शक्ति का उपयोग करते हैं और अधिक स्थान और रखरखाव की आवश्यकता होती है।