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

# from django.contrib.auth.models import User


class RegistrationForm(forms.ModelForm):
    """
    Registration form for User. Import omitted for performance.
    """
    password_1 = forms.CharField(required=True, widget=forms.PasswordInput)
    password_2 = forms.CharField(required=True, widget=forms.PasswordInput)
    username = forms.CharField()
    email = forms.CharField(widget=forms.EmailInput)

    # class Meta:
    #     model = User
    #     fields = ('username', 'email')
-2
pawqo 1 सितंबर 2019, 14:09

1 उत्तर

सबसे बढ़िया उत्तर

इसलिए मैं सोच रहा हूं कि आयात करने के बजाय DRY नियम की उपेक्षा करने वाला मौसम अजगर और django में प्रदर्शन के लिए अच्छा है।

आमतौर पर नहीं। वास्तव में DRY अक्सर प्रदर्शन में सुधार करेगा। यहां तक ​​​​कि अगर यह थोड़ा कम कुशल कोड में परिणत होता है, तो यह केवल एक ऐसी चीज है जिसकी आमतौर पर एक लागत होती है जब आप प्रोग्राम को लोड करते हैं, इसलिए एक स्थिर लागत, एक रैखिक नहीं।

यदि आप एक मॉड्यूल आयात करते हैं। पायथन जाँच करेगा कि क्या उसके पास पहले से ही महत्वपूर्ण है कि मॉड्यूल पहले स्थान पर है। उस स्थिति में यह फ़ाइल को फिर से लोड नहीं करेगा। यह उस मॉड्यूल में ऑब्जेक्ट्स के कुछ संदर्भों को स्थानीय चर के रूप में पास करेगा।

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

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

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

पायथन सबसे कुशल भाषा नहीं है। यह आंशिक रूप से इसकी बहुत गतिशील प्रकृति के कारण है। विचार यह है कि "हार्डवेयर सस्ता है, प्रोग्रामर महंगे हैं " [कोडिंगहॉरर]. तो भले ही आपका प्रोग्राम थोड़ा कम कुशल हो, लेकिन आमतौर पर इसमें ज्यादा खर्च नहीं होता है, क्योंकि आप एक तेज मशीन खरीद सकते हैं। सीपीयू से अंतिम चक्र लेना अधिक महंगा है, क्योंकि इसमें बहुत सारे प्रोग्रामिंग प्रयास होंगे, जो आमतौर पर तेज मशीन की तुलना में अधिक महंगा होता है।

1
Willem Van Onsem 2 सितंबर 2019, 11:28