क्या परिवर्तनशील नाम वेबसाइटों के प्रदर्शन को प्रभावित करते हैं?

Question

क्या वैरिएबल नाम वेबसाइट के प्रदर्शन को प्रभावित करते हैं? मुझे पता है कि यह बहुत कम संख्या होगी, लेकिन फिर भी कोई भी प्रदर्शन के पहलू में एक लंबे चर नाम का चयन नहीं करने का कारण प्रदान कर सकता है?

Comments

कृपया अपना प्रश्न स्पष्ट करें - यह चर कहाँ है और यह किस भाषा में लिखा गया है?

— ल्यूक ग्राहम

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

— माइकल जेवी

मैं PHP का उपयोग कर रहा हूँ ..

— अविनाश

... और आप xpertdeveloper.com के मालिक हैं?

— जिम जी।

हाय अविनाश क्या आप अपने सवाल में अपने तर्क के बारे में सोच सकते हैं कि यह मामला हो सकता है?

Answer 1

क्या कोई भी प्रदर्शन के पहलू में एक लंबे चर नाम का चयन न करने के कारण प्रदान कर सकता है?

माइकल ने उत्तर को कवर किया (यानी नहीं) लेकिन चर नाम प्रोग्रामर के प्रदर्शन को प्रभावित करते हैं । यदि आप एक नए डेवलपर या किसी ऐसे व्यक्ति को लाते हैं, जो कोड से अपरिचित है, तो लंबे और / या भ्रमित करने वाले चर नाम हो सकते हैं और यह समझने की प्रक्रिया को धीमा कर सकता है।

सामान्य तौर पर, आप लघु, वर्णनात्मक चर नामों का उपयोग करना चाहते हैं क्योंकि वे पढ़ना आसान है। सोचिए अगर आपको 10 साल के लिए अपने कोड को नजरअंदाज करना पड़े तो फिर से सब कुछ समझ लें। आप बल्कि "getInput" या "getInputFromUserWhoInputsStringOrElseInformReaderOfError" पढ़ेंगे? (बेशक अतिशयोक्ति: पी)

हालांकि, ऐसे समय होते हैं, जब थोड़ा लंबा नाम रखना फायदेमंद हो सकता है। उदाहरण के लिए, getBirdaydayInput () getInput () की तुलना में बहुत अधिक वर्णनात्मक होगा। आप एक बिंदु पर सरलीकरण करना चाहते हैं लेकिन ओवरसिम्प्लीफिकेशन भी समस्याग्रस्त हो सकता है।

Comments

लंबे नामों को पढ़ने के लिए बेहतर है, अगर आपको "getInputFromUserWhoInputsStringOrElseInformReaderOfError" मिलता है, तो आपको दस्तावेज़ीकरण पढ़ने की आवश्यकता नहीं है कि यह फ़ंक्शन क्या है, यदि आपको "getput" मिल जाए। और 10 साल बाद प्रलेखन गलत, या अधूरा, या गायब हो जाएगा। getInputFromUserWhoInputsStringOrElseInformReaderOfError निश्चित रूप से लंबी है, लेकिन यह समझने के लिए कि यह लंबा है क्या बेहतर है (और मुझे परवाह नहीं है कि महिलाओं का कहना है कि आकार कोई फर्क नहीं पड़ता)।

— Dainius

मैं इस मामले में असहमत हूं। मुझे लगता है कि कोड को पढ़ने से यह समझना बहुत आसान होगा कि getInput () क्या करता है, खासकर अगर यह "अमान्य इनपुट" या इसके ठीक बाद कुछ प्रिंट करता है। निश्चित रूप से ऐसे समय होते हैं जब लंबा नाम बेहतर हो सकता है - मैं इसे संपादित करूँगा!

— ब्लैकजैक

inc यह संदर्भ से निर्भर करता है, लेकिन मेरे अनुभव में नाम बेहतर है (लेकिन तब तक नहीं जब तक getInputFromUserWhoInputsStringOrElseInformReaderOfError)। और file.read के रूप में वास्तव में महत्वपूर्ण संदर्भ () file.readAllFileAsByteArray () की तुलना में तेज है। लेकिन जैसा कि मैंने कहा आमतौर पर IMHO नाम अधिक जानकारी प्रदान करता है।

— Dainius

यदि दस्तावेज़ गलत है, अधूरा है, या गायब है, तो कोडबेस को वैसे भी बर्बाद कर दिया गया है।

— क्रिस्टोफर महान

यह एक प्रश्न का उत्तर दे रहा है जो नहीं पूछा गया था।

Answer 2

नहीं यह नहीं होगा। सामान्यतया, जब कोड संकलित किया जाता है, तो चर नाम को उनके द्वारा निर्दिष्ट मेमोरी पते से बदल दिया जाता है। कंप्यूटर को चर नामों के बारे में कुछ नहीं पता; वे केवल यह जानना चाहते हैं कि मूल्य कहाँ संग्रहीत हैं।

चर प्रतीक हैं, अधिक कुछ नहीं। वे हेक्स मानों को नामों से प्रतिस्थापित करते हैं ताकि प्रोग्रामर को समझने में आसान समय हो कि वे क्या कर रहे हैं। इसलिए, छोटे परिवर्तनीय नामों को चुनकर कोई प्रदर्शन को बढ़ावा नहीं मिलेगा।

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

Comments

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

— गेविन

@ गेविन व्याख्या की गई भाषाओं के लिए भी सही है - "जेआईटी प्रथम व्याख्या"। अधिकांश व्याख्या की गई भाषाएं अब संकलित होती हैं क्योंकि वे लाइन निष्पादन के बजाय एएफएआईके द्वारा निष्पादित होते हैं।

— माइकल के।

माइकल - संकलन करने के लिए, फ़ाइल को पहले मेमोरी में पढ़ा जाना चाहिए। यह प्रक्रिया फ़ाइल की लंबाई के आधार पर अधिक समय लेगी। लंबी चर नाम = लंबी फाइलें।

— गैविन

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

— bdsl

Answer 3

जब तक आप ऑप-कोड कैश (जिसे "PHP एक्सीलेटर" भी कहा जाता है) का उपयोग कर रहे हैं , तब वास्तव में एक प्रभाव होता है। लेकिन यह प्रभाव इतना कम है, कि इसे उपेक्षित किया जा सकता है। यदि आप op-code कैश का उपयोग करते हैं, तो शून्य प्रभाव पड़ता है।

Comments

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

— एसएफ।

लेकिन जाहिर है कि प्रभाव संचित है, इतना बड़ा अनुप्रयोग, बड़ा प्रभाव, सही?

— n00dles

Zend Opcache को अब PHP के साथ कई वर्षों के लिए भेज दिया गया है, इसलिए सभी को इसका उपयोग करना चाहिए। मुझे लगता है कि यह आम तौर पर डिफ़ॉल्ट रूप से सक्षम है।

— bdsl

Answer 4

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

हालाँकि ऐसा करने के साथ किया जाने वाला प्रदर्शन निरर्थक होगा, और संभवत: एक पूरी स्क्रिप्ट के लिए एक मिलीसेकंड के अंशों के क्षेत्र में होगा। आप इसे हमेशा एक नमूना स्क्रिप्ट के साथ आज़मा सकते हैं, और एक समय-निर्धारण विधि का उपयोग कर सकते हैं जैसे कि http://www.developerfusion.com/code/2058/determine-execution-time-in-php/ पर विस्तृत लेकिन यह शायद नहीं होगा फ़ाइल को पढ़ने के बाद तक समय शुरू करना। इसके अतिरिक्त, रिट्रीस के बीच निष्पादन का समय चर नाम की लंबाई के बीच के अंतर की तुलना में कहीं अधिक होगा, इसलिए आपको महत्वपूर्ण संख्या में रिट्रीज़ करने और प्रत्येक का औसत लेने से पहले आपको करना होगा। दूरस्थ रूप से सार्थक औसत प्राप्त करें।

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

तो संक्षेप में, चर लंबाई के नाम के बारे में चिंता न करें, बल्कि स्वच्छ, सार्थक कोड लिखने पर ध्यान केंद्रित करें।

Answer 5

हो सकता है :

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

जावास्क्रिप्ट फ़ाइलों को छोटा करने के अलावा, वेब एप्लिकेशन / वेब साइट के लिए कोई भी अनुकूलन प्रयास, अन्य पहलुओं पर बेहतर खर्च किए जाएंगे।

Answer 6

हां, यह होगा, लेकिन उस अर्थ में नहीं जिसके बारे में आप सोच रहे हैं।

खराब चर नामों के साथ, डेवलपर्स आसानी से स्रोत कोड में भ्रमित हो जाएंगे। इसे पढ़ना और समझना कठिन होगा।

अंत में, स्रोत कोड को बनाए रखना कठिन होगा और इसे विकसित करना लगभग असंभव होगा। यह अनिवार्य रूप से उच्च रखरखाव लागत, उच्च विकास लागत, अधिक बग और खराब प्रदर्शन का नेतृत्व करेगा ।

परिवर्तनीय नाम का रनटाइम पर बिल्कुल कोई प्रभाव नहीं होगा, और संकलन समय पर पूरी तरह से नगण्य होगा। लेकिन बुरे नाम अनिवार्य रूप से खराब प्रदर्शन का कारण बनेंगे क्योंकि कोई भी कोड को नहीं समझता है और यह एक के ऊपर एक हैक के ढेर में समाप्त होता है, जिससे चीजें हर बार खराब होती हैं।

अच्छे चर नाम के बारे में जानने के लिए इन्हें पढ़ें: http://tottinge.blogsome.com/meaningfulnames

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

Answer 7

जवाब स्पष्ट रूप से हाँ है, php के संबंध में।

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

Comments

लेकिन आप गलत हैं। कोई भी सभ्य php दुभाषिया केवल एक बार कोड को पार्स करेगा। Php दुभाषियों को लिखने वाले लोग मूर्ख नहीं हैं।

— gnasher729

@ gnasher729 आप यह व्याख्या कर रहे हैं कि दुभाषिया या पूरा सर्वर कैसे काम करता है और आपको ऐसा कभी नहीं करना चाहिए। यहां तक ​​कि अगर यह प्रति रन केवल एक बार पार्स करेगा, तो यह प्रत्येक रन पर फिर से पार्स कर सकता है और पार्स किए गए प्रतिनिधित्व को कैश नहीं करेगा (अन्य सिस्टम ऐसा करेंगे लेकिन आप पहले से नहीं जान सकते हैं)। और आम तौर पर अधिक बाइट्स एक स्क्रिप्ट है जितनी देर तक यह पार्स होगा। तो डायोरोथिस आम तौर पर गलत नहीं है, केवल एक विशिष्ट प्रणाली के बारे में गलत हो सकता है।

— मेकी

Answer 8

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

तो आपके प्रश्न का उत्तर देने के लिए ("यह प्रदर्शन को प्रभावित करता है"): हाँ, लेकिन उस तरीके से नहीं जैसा आप पसंद करते हैं।