चूंकि PHP कोड ठीक से चलाएगा, भले ही यह अनिर्धारित इंडेक्स और स्थैतिक आदि के रूप में गैर-स्थैतिक विधियों के रूप में चेतावनी के साथ छेड़छाड़ की गई हो, सवाल यह है कि, यदि मैं अपने कोड से सभी नोटिस और चेतावनियों को हटाने के लिए समय बिताता हूं क्या यह को तेजी से चलाएगा?क्या php चेतावनी के बिना तेजी से चलाता है?
मैंने एक लेख बुक किया जिसमें लेखक ने इसके बारे में कुछ बेंचमार्क किए; दुर्भाग्य से, उस में फ्रेंच है ... लेकिन यहाँ यह है (हो सकता है आप इसे के कुछ हिस्सों समझ जाएंगे): Ne faites pas d'erreur
और यहाँ नंबर दिए गए हैं, जो लोग नहीं पढ़ते फ्रेंच मदद करने के लिए:
error_reporting और display_errors के साथ सक्षम: 5,162.76 एमएसdisplay_errors विकलांग: 136.18 एमएसerror_reporting साथ भी अक्षम: 117.79 एमएसकि, हाँ, PHP कोड के बिना नोटिस/चेतावनी/त्रुटियों तेज़ चलता है, भले ही वे प्रदर्शित नहीं होते हैं जिसका मतलब है न ही रिपोर्ट की।
Derick Rethans का कहना है इस लेख में एक ही बात: Five reasons why the shut-op operator (@) should be avoided(के हवाले से):
कारण 3: यह धीमी है (भाग 2)
जब भी पीएचपी एक त्रुटि उत्पन्न करता है आंतरिक रूप से संदेश, यह संसाधित हो गया है और पूरी तरह से स्वरूपित संदेश तक स्वरूपित है जो आउटपुट स्ट्र ब्राउज़र के लिए आशंका।
error_reportingसेटिंग प्रदर्शित होने से ठीक पहले ही जांच की गई है। हालांकि, यह @ -ऑपरेटर से विशेष रूप से संबंधित नहीं है।
त्रुटि संदेशerror_reportingसे पहले पूरी तरह से स्वरूपित किया गया है याdisplay_errorsउस मामले के लिए।
चेतावनियों की मात्रा पर निर्भर करता है, लेकिन त्रुटि संदेशों को छिपाने के दौरान PHP में त्रुटि प्रबंधन, अपेक्षाकृत महंगा है।
आप अनुमान लगाने के लिए प्रभाव सी स्तर पर रूपरेखा करना होगा क्या: valgrind स्थापित (यह मानते हुए आप लिनक्स पर कर रहे हैं) और फिर चलाने
callgrind /path/to/bin/php /path/to/script.php
यह एक फ़ाइल callgrind.12345 या तथाकथित उत्पन्न करता है, इस फ़ाइल को kcachegrind जैसे ऐप में लोड करें और php_error_docref0 या php_error_cb देखें, यह देखने के लिए कि त्रुटि हैंडलर में कितना समय व्यतीत किया गया था।
कृपया ऐसा करने पर कैशग्रींड और वालग्रींड दस्तावेज़ों को ध्यान दें और ध्यान दें कि कई सिस्टम-निर्भर चर शामिल हैं।
संपादित करें: ओह एक और नोट: मुझे लगता है कि रास्ता डाटाबेस और इसी तरह के सिस्टम से बात करते समय अधिक समय बिताया जाता है। और फिर भी एक और अतिरिक्त नोट: फिक्सिंग नोटिस आमतौर पर कोड को भविष्य में बदलावों के लिए अधिक मजबूत बनाता है, इसलिए यह प्रदर्शन से स्वतंत्र एक अच्छा विचार है।
संपादन के लिए +1 :-) – TheHippo
मैं इसे ज्यादातर मामलों के लिए "महत्वपूर्ण" सुधार नहीं कहूंगा, लेकिन किसी भी प्रकार की त्रुटियों को उत्पन्न करने वाला कोड चलाना कोड स्वाभाविक रूप से उस कोड से तेज़ी से चलता है जिसे हर दूसरे लाइन में एक स्टैक ट्रेस उत्पन्न करना होता है।
चेक आउट: http://www.noamdesign.com/Web-Design-Blog/15-tips-to-optimizing-your-php-code/ मामूली अनुकूलन के बारे में अधिक जानकारी के लिए आप अपने कोड में कर सकते हैं।
अपने अनुभव में, मुझे पता चला है कि 9 5% कोड अनुकूलन आमतौर पर आपके डेटाबेस का उपयोग करने के तरीके से संबंधित है।
हू, मुझे पोस्ट करने के बाद एहसास हुआ: यह अंतिम परीक्षण के लिए मेरा 1,000 वां उत्तर ^^ –
+1 है। नोटिस और चेतावनियां आपकी सबसे खराब त्रुटियां हैं क्योंकि वे आपको तुरंत समस्या को ठीक करने के लिए मजबूर नहीं करते हैं। गुम सरणी सूचकांक को ठीक करना इतना आसान है, लेकिन शायद ही कभी संबोधित किया जाता है। निजी तौर पर, मैं हर सूचना/चेतावनी का इलाज करता हूं जैसे कि यह E_FATAL है। – Dereleased
अब, एक सवाल यह है कि त्रुटि जांच से हैंडलर की तुलना में अधिक देरी नहीं होगी। मेरा मतलब है: अस्तित्व के लिए परीक्षण, आदि। मुझे गलत मत समझो: मुझे चेतावनियों और नोटिस से नफरत है। मुझे हाल ही में ऐसी परियोजना मिली है लेकिन उपर्युक्त परिणाम मुझे जोखिम का निवेश करने के लिए मना नहीं करते हैं। – Galvani