जब आप किसी फ़ंक्शन के बिग O निष्पादन समय को बदलते हैं तो आप इसे क्या कहते हैं [बंद]

Question

मान लीजिए कि मेरे पास एक फ़ंक्शन है जो O(n^2)समय में एक डेटाबेस को सॉर्ट करता है। मैं इसे फिर से शुरू करने के बारे में जाना चाहता हूं, इसलिए यह O(n log(n))समय में चलता है , और ऐसा करने पर मैं मूल तरीके को बदल दूंगा, जबकि रिटर्न वैल्यू और इनपुट को बराबर रखते हुए ऑपरेशन चलता है।

मैं इस रीफैक्टरिंग गतिविधि को क्या कहूँ?

"स्पीडिंग-अप-इफाइंग" बिलकुल सही नहीं लगता, क्योंकि आप उस बड़ी O की गति को बदले बिना एक एल्गोरिथ्म को तेज बना सकते हैं जिस पर उसे निष्पादित किया गया है।

"सरलीकरण" भी सही नहीं लगता है।

मैं इस गतिविधि को क्या कहूँ?

अपडेट करें

सबसे अच्छा जवाब जो मुझे मिल सकता है वह है विषमतापूर्ण समय जटिलता को कम करना।

Comments

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

— नेट

यह

— रिफैक्टिंग

कड़ाई से बोलना, O(log(n))समय में चलने वाला कार्य भी O(n^2)समय में चलता है । का अर्थ O(n^2)है "द्विघात से अधिक तेजी से नहीं बढ़ता है।" आपका शायद मतलब थाटा (लॉग (एन)) है जिसका अर्थ है "जितनी तेजी से बढ़ता है log(n)"। en.wikipedia.org/wiki/…

— २०

<पांडित्य> आपने किसी फ़ंक्शन के बड़े o निष्पादन समय को नहीं बदला। एक फ़ंक्शन एक डोमेन और एक कोडोमैन के बीच एक संबंध है और कार्यान्वयन पर आपके पुनीत मानव प्रयासों से स्वतंत्र है। इसके बजाय आप एक बेहतर प्रदर्शन कर एल्गोरिथ्म में पाया गया कि औजार समारोह </ पंडिताऊ> <मानव> अच्छा काम </ मानव>

— एमोरी

@Theonlygusti: यह निर्भर करता है। यदि फ़ंक्शन पहले जटिलताओं पर एक गारंटी / गारंटी देता है, तो यह पुन: सक्रिय नहीं है। अगर इसने कुछ गारंटी नहीं दी, तो यह फिर से काम कर रहा है। अगर यह भी गारंटी नहीं बनाने के बारे में स्पष्ट था, यह विशेष रूप से एक refactoring है।

— १०

Answer 1

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

ऐसा करने पर मैं ऑपरेशन चलाने के मूल तरीके को बदल दूंगा

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

EDIT: मैंने फाउलर की रीफैक्टरिंग सूची की जाँच की , और इस ~ 100 नाम के रिफैक्टरिंग के बीच, बहुत अंतिम एक को "सबस्टिट्यूट एल्गोरिथम" कहा जाता है । इसलिए यदि हम इसे विहित संदर्भ के रूप में लेते हैं, तो एक छोटा, धूसर क्षेत्र होता है, जहाँ वर्णित रूप के अनुकूलन को एक विशेष प्रकार का रिफैक्टरिंग कहा जा सकता है (लेकिन IMHO एक सामान्य नहीं)। यह भी ध्यान दें, सभी रिफ्लेक्टरिंग के साथ फाउलर का लक्ष्य हमेशा यह था कि डिजाइन को बेहतर बनाए रखने के लिए इसे बनाए रखने के बिना मौजूदा कोड की मेंटेनेंस और इवॉल्विबिलिटी पर ध्यान दिया जाए और परफॉर्मेंस ऑप्टिमाइजेशन न हो।

Comments

वास्तव में? मुझे लगता है कि जब तक आवश्यकताओं में बदलाव नहीं होगा तब तक रिफैक्टिंग सही है। तो .. नहीं, अगर फ़ंक्शन को बबलोर्ट कहा जाता है, लेकिन हाँ अगर इसका सिर्फ

— इवान

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

— डेडुप्लिकेटर

मैं उस व्यक्ति की शुरुआती प्रस्तुति पर था जिसने रिफैक्टिंग (फाउलर?) का आविष्कार किया और गढ़ा था और यह पूरा विचार स्वचालित प्रोग्रामिंग और कोड में सुधार योग्य साबित हुआ था जो कि इनपुट बनाम आउटपुट पर कोई प्रभाव नहीं था।

— सेंटिनल

@Steve। माना। मैं केवल इस आम सहमति में जोड़ रहा था कि बिग ओ सुधार एल्गोरिथम सुधार का प्रतिनिधित्व करते हैं, न कि उन एल्गोरिदम का प्रतिनिधित्व करने या बनाए रखने में सुधार। दूसरे शब्दों में, गतिविधि फिर से लिखना है

— प्रहरी

@ सच: हां, मुझे पता था कि, मेरे जवाब में एक नोट जोड़ने के बारे में सोचा था। मेरा संपादन केवल एक नोट था कि यह स्पष्ट करने के लिए कि एक छोटा, ग्रे क्षेत्र है।

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

Answer 2

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

Answer 3

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

चेतावनी : एसिम्प्टोटिक समय की जटिलता को कम करना व्यावहारिक रूप से अनुकूलन के रूप में आवश्यक नहीं है । अक्सर असमान्त रूप से गैर-इष्टतम एल्गोरिदम का उपयोग किया जाता है क्योंकि आदानों की सीमा पर कार्यक्रम वास्तव में कम इष्टतम एल्गोरिदम के संपर्क में होता है जो बेहतर प्रदर्शन करते हैं।

Answer 4

यह संदर्भ-निर्भर होगा।

"फिक्सिंग एक द्विघात रनटाइम प्रदर्शन बग" आम तौर पर मैं जो देखता हूं। हालांकि, चाहे वह फिक्सिंग (एक कोड परिवर्तन) के लिए संदर्भ-निर्भर हो।

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

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

सॉफ्टवेयर प्रदर्शन के बारे में ग्राहकों की बहुत सारी शिकायतें इन दो श्रेणियों में आती हैं:

• संपूर्ण प्रणाली (सॉफ्टवेयर और हार्डवेयर) अनुमानित उपयोग के आधार पर निर्दिष्ट की गई थी। पिछले हफ्ते, सब कुछ ठीक चलता है, एक निश्चित कार्यक्षमता 5 सेकंड से कम समय लेती है। इस हफ्ते, एक अद्यतन स्थापित करने के बाद, एक ही कार्यक्षमता 1 मिनट से अधिक समय लेती है।

  • यह पहले के बेंचमार्क प्रदर्शन के साथ तुलना है। ग्राहक भविष्य के प्रदर्शन को मानव समय-पैमाने (सेकंड से मिनट तक) के पूर्ण यार्डस्टिक में रखता है।

• मैंने सिस्टम को 100 नौकरियां दीं। किसी एकल कार्य के लिए लगने वाले समय की तुलना में इसे 400x प्रक्रिया करने में समय क्यों लग रहा है?

  • ग्राहक प्रसंस्करण समय को रैखिक होने की उम्मीद करता है। वास्तव में, ग्राहक समझ नहीं सकता है या स्वीकार नहीं करता है कि ऐसे कार्य मौजूद हैं जो रैखिक की तुलना में धीमे हैं।

इस कारण से, ग्राहक निष्पादन समय को बग होने पर विचार करेगा यदि दोनों सत्य हैं:

• रैखिक की तुलना में धीमी
• ध्यान देने योग्य (यानी मानव समय सीमा के भीतर (सेकंड या मिनट से अधिक) विशिष्ट कार्य आकार दिए गए हैं)

वैध तर्क जो बताते हैं कि द्विघात रनटाइम एल्गोरिथ्म एक समस्या उत्पन्न नहीं करता है (यानी कोड परिवर्तन के लायक नहीं है):

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

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

यह सॉफ़्टवेयर ग्राहकों पर लागू होता है, लेकिन यदि आप किसी सॉफ़्टवेयर लाइब्रेरी या API फ़ंक्शन के उपयोगकर्ताओं को "ग्राहक" मानते हैं, तो उत्तर अभी भी लागू होगा।

Answer 5

यदि मूल एल्गोरिथ्म को सही ढंग से लागू किया गया था (या किसी भी कीड़े जहां अप्रासंगिक है) तो "एल्गोरिथ्म को बदलना" या "एल्गोरिथ्म प्रतिस्थापन" , क्योंकि ऐसे परिवर्तनों का मतलब है कि आप ठीक कर रहे हैं; पहले उपयोग किए गए एक के लिए अलग-अलग समय जटिलता के साथ एक एल्गोरिदम को प्रतिस्थापित करना।

यदि पिछली बार जटिलता कार्यान्वयन में एक बग के कारण थी (उदाहरण के लिए, आप गलती से एक अनुक्रम पर एक आंतरिक लूप के शुरुआती बिंदु को रीसेट कर रहे थे, ताकि ओ (एन) क्या होना चाहिए था ओ (एन ² )) तो "फिक्सिंग" ) एक द्विघात लागत बग " या समान।

एक ओवरलैप है, इस तरह के मामले में कोड पर प्रभाव समान है यदि आप शुरू से जानते हैं कि काम ओ (एन) समय में किया जा सकता है और ओ (एन ² ) समय एक त्रुटि थी, या यदि आपने पहली बार इसे जानबूझकर O (n ² ) समय में लागू किया था और तब एहसास हुआ कि यह अभी भी प्रारंभिक बिंदु को रीसेट किए बिना सही ढंग से काम करेगा, और इसलिए O (n ² ) एक के लिए O (n) एल्गोरिदम प्रतिस्थापित किया गया ।

Answer 6

एक आदेश / परिमाण के आदेश द्वारा गति अनुकूलन। यद्यपि यह गणितीय रूप से गलत भाषा है, लेकिन यह ऑर्डर के बदले जाने के विचार को सबसे अच्छा बताता है।

स्केलेबिलिटी में सुधार हुआ। सुना भी।