على محمل الجد ، هل يجب أن أكتب رمز PHP السيئ؟ [مغلق

Question

أقوم ببعض أعمال PHP مؤخرًا ، وفي جميع التعليمات البرمجية التي رأيتها ، يميل الناس إلى استخدام طرق قليلة. (يميلون أيضًا إلى استخدام القليل من المتغيرات ، لكن هذه مشكلة أخرى.) كنت أتساءل عن سبب ذلك ، ووجدت هذه الملاحظة "استدعاء دالة مع معلمة واحدة ويستغرق جسم وظيفة فارغ نفس الوقت تقريبًا مثل 7-8 $ عمليات LocalVar ++. إن مكالمة طريقة مماثلة هي بالطبع حوالي 15 دولارًا من عمليات LocalVar ++ " هنا.

هل هذا صحيح ، حتى عندما تم تجميع صفحة PHP وتخزينها مؤقتًا؟ هل يجب أن أتجنب استخدام الأساليب قدر الإمكان للكفاءة؟ أحب أن أكتب رمزًا تنظيماً جيداً ، قابل للقراءة الإنسان مع طرق أينما تكرر كتلة التعليمات البرمجية. إذا كان من الضروري كتابة التعليمات البرمجية المسطحة بدون طرق ، فهل هناك أي برامج ستقوم "مضمّنة" بالهيئات؟ وبهذه الطريقة يمكنني كتابة رمز جميل ثم قبيح قبل النشر.

بالمناسبة ، فإن الكود الذي كنت أبحث عنه هو من CORE JOOMLA 1.5 والعديد من الإضافات WordPress ، لذلك أفترض أنهم أشخاص يعرفون ماذا يفعلون.

ملحوظة: يسعدني أن الجميع قد قفزوا على هذا السؤال للحديث عن التحسين على العموم, ، ولكن في الواقع نحن نتحدث عن التحسين في اللغات المفسرة. على الأقل بعض التلميحات من حقيقة أننا نتحدث عن PHP سيكون لطيفًا.

Answer 1

أعتقد أن Joomla و WordPress ليسا أعظم أمثلة على جيد رمز PHP ، مع عدم وجود جريمة. ليس لدي أي شيء شخصي ضد الأشخاص الذين يعملون عليها ، ومن الرائع كيف يمكّن الناس من امتلاك موقع ويب/مدونة وأعلم أن الكثير من الناس يقضون كل وقت فراغهم في أي من هذه المشاريع ولكن جودة الكود ضعيفة إلى حد ما (مع لا اقصد التقليل من شأنك).

مراجعة إعلانات الأمن خلال العام الماضي إذا كنت لا تصدقني ؛ على افتراض أنك تبحث عن أداء من أي من الاثنين ، فإن الكود لا يتفوق هناك أيضًا. لذلك ليس رمزًا جيدًا بأي حال من الأحوال ، لكن WordPress و Joomla يتفوقان على الواجهة الأمامية - سهل الاستخدام للغاية ، ويحصل الأشخاص على موقع ويب ويمكنهم القيام به أمور.

وهذا هو السبب في أنهم ناجحون للغاية ، لا يختارهم الأشخاص بناءً على جودة التعليمات البرمجية ولكن على ما مكنهم من القيام به.

للإجابة على سؤال أدائك ، نعم ، صحيح أن جميع الأشياء الجيدة (الوظائف ، الفصول ، وما إلى ذلك) تبطئ تطبيقك. لذلك أعتقد أنه إذا كان التطبيق/البرنامج النصي الخاص بك في ملف واحد ، فليكن ذلك. لا تتردد في الكتابة رمز PHP السيئ ومن بعد.

بمجرد التوسع والبدء في تكرار التعليمات البرمجية ، يجب عليك النظر في التداول (في السرعة) التي يجلبها كتابة التعليمات البرمجية القابلة للصيانة. :-)

Imho هذه التجارة صغيرة إلى حد ما بسبب شيئين:

1. وحدة المعالجة المركزية هو رخيص.
2. المطورين غير صحيح رخيص.

عندما تحتاج إلى العودة إلى الكود الخاص بك في غضون ستة أشهر من الآن ، فكر في ما إذا كانت هذه الثواني النانوية قد تم حفظها ، فلا تزال تضيف ما يصل عندما تحتاج إلى إصلاح خطأ سيء (ثلاث أو أربع مرات ، بسبب الكود المكرر).

يمكنك أن تفعل كل أنواع الأشياء لجعل PHP تعمل بشكل أسرع. بشكل عام يوصي الناس بتخزين ذاكرة التخزين المؤقت ، مثل APC. APC رائع حقا. يقوم بتشغيل جميع أنواع التحسينات في الخلفية بالنسبة لك ، على سبيل المثال تخزين رمز Bytecode لملف PHP ويوفر لك أيضًا وظائف في Userland لحفظ البيانات.

لذلك على سبيل المثال ، إذا قمت بتحليل ملف التكوين في كل مرة تقوم فيها بتشغيل قرص البرنامج النصي ، فإن I/O أمر بالغ الأهمية. مع بسيطة APC_STORE () و apc_fetch () يمكنك تخزين ملف التكوين المحجوب إما في ذاكرة التخزين المؤقت (RAM) المستندة إلى الملف (RAM) واسترداده من هناك حتى انتهاء ذاكرة التخزين المؤقت أو يتم حذفها.

APC ليس ذاكرة التخزين المؤقت الوحيدة ، بالطبع.

Answer 2

ما مقدار "الكفاءة" التي تحتاجها؟ هل قمت بالقياس؟ التحسين السابق لأوانه هو جذر كل الشر ، والتحسين بدون قياس هو دائما سابق لأوانه.

تذكر أيضا قواعد نادي التحسين.

1. القاعدة الأولى لنادي التحسين هي أنك لا تحسن.
2. القاعدة الثانية لنادي التحسين هي أنك لا تتحسن دون القياس.
3. إذا كان تطبيقك يعمل بشكل أسرع من بروتوكول النقل الأساسي ، فقد انتهى التحسين.
4. عامل واحد في وقت واحد.
5. لا يوجد Marketroids ، لا جداول MarketRoid.
6. سيستمر الاختبار طالما كان عليه.
7. إذا كانت هذه هي الليلة الأولى في نادي الأمثل ، فيجب عليك كتابة حالة اختبار.

Answer 3

يجب أن ترى الردود على هذا السؤال: هل يجب أن يهدف المطور إلى قابلية القراءة أو الأداء أولاً؟

لتلخيص الإجماع: ما لم تكن تعرف حقيقة (من خلال الاختبار/التنميط) ، يجب معالجة أدائك في مجال معين ، فإن قابلية القراءة أكثر أهمية بكثير.

Answer 4

في 99 ٪ من الحالات ، يجب أن تقلق بشكل أفضل بشأن فهم الكود. اكتب الكود سهل الاختبار وفهم و mantain.

في هذه الحالات القليلة التي يكون فيها الأداء أمرًا بالغ الأهمية ، فإن اللغات البرمجية مثل PHP ليست أفضل خيار لك. هناك سبب يتم كتابة العديد من وظائف المكتبة الأساسية في PHP في C ، بعد كل شيء.

Answer 5

شخصياً ، على الرغم من أنه قد يكون هناك حمولة لمكالمة دالة ، إذا كان ذلك يعني أنني أكتب الرمز مرة واحدة (معلمة) ، ثم استخدمه في 85 مكانًا ، أنا طريق إلى الأمام لأنه يمكنني إصلاحه في مكان واحد.

تميل لغات البرمجة النصية إلى إعطاء الناس فكرة أن "جيد بما فيه الكفاية" و "الأعمال" هي المعايير الوحيدة التي يجب مراعاتها عند الترميز.

Answer 6

خاصة مع مترجم سريع مثل PHP ، لا أعتقد أن عدم قابلية القراءة/الصيانة يستحق أبدًا الكفاءة التي قد تكسبها (أو لا!).

وملاحظة حول WordPress: لقد قمت بالكثير من تصفح رمز WordPress. لا تفترض أن هؤلاء الأشخاص يعرفون أي شيء عن الكود الجيد ، من فضلك.

Answer 7

للإجابة على سؤالك الأول ، نعم هذا صحيح وصحيح أيضًا بالنسبة إلى رمز OP المترجم. نعم ، يمكنك جعل التعليمات البرمجية الخاصة بك بشكل أسرع عن طريق تجنب مكالمات الوظائف إلا في الحالات القصوى التي ينمو فيها الكود الخاص بك بسبب ازدواج الرمز.

يجب عليك أن تفعل ما تحب "أحب أن أكتب رمزًا منظمًا جيدًا ، قابل للقراءة الإنسان مع طرق أينما تكرر كتلة التعليمات البرمجية".

إذا كنت سترتكب هذه الوحشية الرهيبة لإزالة جميع مكالمات الوظائف على الأقل ، فاستخدم Profiler وفعل ذلك فقط إلى 10 ٪ من الكود الخاص بك المهم.

Answer 8

مثال على كيفية يؤدي التحسين الصغير إلى تباطؤ الماكرو:

إذا كنت تفكر بجدية في الوظائف التي تضم يدويًا ، ففكر في حلقات Unrolling يدويًا.

JMPs باهظة الثمن ، وإذا كان بإمكانك التخلص من الحلقات عن طريق إلغاء التخلص من جميع الكتل المشروطة ، فستقوم بإزالة كل هذا الوقت الذي يضيع فيه مجرد البحث حول ذاكرة التخزين المؤقت لوحدة المعالجة المركزية.

إن زيادة المتغير في وقت التشغيل بطيء أيضًا ، وكذلك سحب الأشياء من قاعدة البيانات ، لذلك يجب عليك ضم جميع هذه البيانات في الكود الخاص بك أيضًا.

في الواقع ، فإن تحميل مترجم فوري لتنفيذ التعليمات البرمجية ونسخ الذاكرة إلى مستخدم أمر مضيء بشكل شامل ، فلماذا لا نقوم بحساب جميع الصفحات الممكنة مسبقًا وتخزين كل صفحة في الذاكرة جاهزة للذهاب ، لذا فهي مجرد نسخة من الذاكرة ؟ بالتأكيد هذا سريع!

آه ، لدينا الآن هذا الشيء البطيء الذي يسمى الإنترنت بيننا ، والذي يعيق تجربة المستخدم ويقتصر على مقدار المحتوى الذي يمكننا استخدامه ، وماذا عننا مسبقًا في تحصيل الصفحات مقدمًا ، ونرشئها جميعًا وتشغيلها على الجهاز المحلي للمستخدمين؟ سيكون ذلك سريعًا حقًا!

لكن هذا سوف يضيع دورات وحدة المعالجة المركزية ، والكثير منها ، مع وقت تحميل الصفحة وتقديم محتوى المتصفح ، إلخ ، سنخطي الوسيط ونقدم الصفحات إليهم على الوسائط المطبوعة!. عبقري!.

/أنا تشاهد شركتك تنهار على وجهها بينما تقضي 10 سنوات في الحجم المسبق (باليد) وطباعة صفحات لا يريد أحد رؤيتها.

قد يبدو هذا سخيفًا بالنسبة لك ، ولكن بالنسبة لنا ، فإن ما اقترحته هو مجرد سخيف.

يعد التحسين جيدًا ، ولكن ارسم الخط في مكان ما معقول ، لذا لا داعي للقلق بشأن الأشخاص المستقبليين الذين يعملون على الكود الذي يتتبعك في نومك بسبب وجود قاعدة كود كربي لا يمكن الحفاظ عليها.

ملاحظة: نعم ، أنا استخدم gentoo. كيف حزرت؟

Answer 9

بالطبع يجب ألا تكتب رمز PHP السيئ. ولكن بمجرد أن يكون لديك شيء مكتوب سيئًا ، يمكنك دائمًا استخدام Perfomance كذريعة :-)

Answer 10

هذا هو التحسين السابق لأوانه. على الرغم من أن البيان صحيح أن تكلفة استدعاء الوظيفة أكثر من زيادة متغير عدد صحيح محلي (تكاليف كل شيء تقريبًا أكثر) ، فإن تكاليف استدعاء الوظيفة لا تزال منخفضة للغاية مقارنة باستعلام قاعدة البيانات.

أنظر أيضا:

ويكيبيديا -> التحسين -> عند التحسين

c2.com wiki -> التحسين السابق لأوانه

Answer 11

القوة الرئيسية لـ PHP هي أنه سريع وسهل الحصول على تطبيق عمل. تأتي هذه القوة من فرصة كتابة الكود (السيئ) ولا تزال تعمل بطريقة متوقعة إلى حد ما.

إذا كنت في وضع يسمح لك بالحاجة إلى الحفاظ على بعض دورات وحدة المعالجة المركزية ، فإن PHP ليس ما يجب أن تستخدمه. عندما تؤدي تطبيقات الويب PHP بشكل سيئ ، يكون ذلك أكثر احتمالًا بسبب الاستعلامات غير الفعالة ، وليس سرعة تنفيذ الكود.

Answer 12

إذا كنت قلقًا بشأن كل شيء على الكفاءة ، فلماذا تستخدم لغة البرمجة النصية على الأرض؟ يجب أن تكون برمجة بلغة أسرع بكثير (أدخل لغتك المفضلة هنا) ، مما يؤدي إلى المزيد من التعليمات البرمجية القابلة للقراءة ، ولكنها ستستمر بسرعة ، ولا يزال بإمكانك تهدف إلى أفضل ممارسات الترميز.

على محمل الجد ، إذا كنت ترميز لسرعة التشغيل ، فلن تستخدم PHP على الإطلاق.

Answer 13

إذا قمت بتطوير تطبيقات الويب بنمط معماري MVC ، فيمكنك الاستفادة بشكل كبير من التخزين المؤقت والتسلسل. يمكنك ذاكرة التخزين المؤقت ، أو أجزاء منه ، ويمكنك تسلسل النماذج.

من التجربة ، غالبًا ما تقوم النماذج بتحليل وإنشاء معظم البيانات التي يتم عرضها. إذا كنت تعرف أن نموذجًا معينًا لن يقوم بإنشاء بيانات جديدة بشكل متكرر ، مثل النموذج الذي يوسع خلاصة RSS ، فيمكنك فقط الحصول عليه في مكان ما مع جميع البيانات المحسورة وتحديثه مرة واحدة كل فترة.

Answer 14

إذا نظرت إلى رمز WordPress PHP ، فإنه يمتلك علامات PHP بين HTML الذي يؤدي إلى السباغيتي في ذهني.

PHPBB3 ومع ذلك هو أفضل طريقة في هذا الصدد. على سبيل المثال ، يحتوي على تقسيم صارم بين جزء PHP ، وجزء الأنماط ، والتي هي ملفات من تنسيق XHTML مع علامات {template} ، محفورة بواسطة محرك قالب. وهو أكثر نظافة.

Answer 15

اكتب أمثلة لمدة 10 دقائق وقم بتشغيلها في Profiler.

سيخبرك ذلك الذي هو أسرع للميلي ثانية.

إذا لم يكن لديك مستنير ، فقم بنشرها هنا ، وسأقوم بتشغيلها في Phped Profiler.

أظن أن الكثير من الفرق الزمني ، إن وجد ، يأتي من الاضطرار إلى فتح الملف الذي يتم تخزين الفصل فيه ، ولكن يجب اختبار ذلك أيضًا.

ثم اسأل نفسك عما إذا كنت تهتم كثيرًا ببضع مللي ثانية مقابل الاضطرار إلى الحفاظ على رمز السباغيتي - هل يلاحظ أي من المستخدمين أي وقت مضى؟

يحرر

لن يقوم Profiler بمحاكاة أحجام حركة المرور عالية ، ولكنها ستخبرك بالأسلوب الأسرع لمستخدم واحد ، وأي أجزاء من الكود تستخدم مقدار الوقت. خاصة إذا قمت بتعريف العمليات التي يتم القيام بها مرارًا وتكرارًا - قل 1000 مرة لكل حلقة.

يمكننا أن نفترض (وإن لم يكن دائمًا) أن التعليمات البرمجية الأسرع التي يستخدمها الكثير من الأشخاص ستكون أسرع من الكود الأبطأ الذي يستخدمه الكثير من الأشخاص.

Answer 16

أولئك الذين سيقومون بمحاضرك حول تحسين الكود الدقيق هم نفس الشيء الذي سيكون لديه 50 استعلامات SQL لكل صفحة ، ويستغرقون ما مجموعه ثانيتين ، لأنهم لم يسمعوا مطلقًا عن التنميط. لكن الكود الخاص بهم تم تحسينه !!! (وبطيئة مثل الجحيم)

حقيقة: إضافة خادم ويب آخر ليس من الصعب. تكرار قاعدة بيانات هو. يمكن أن يكون تحسين رمز الويب خسارة صافية إذا أضاف تحميل على DB.

ملاحظة: 2-3 مللي ثانية للحصول على صفحات بسيطة (مثل موضوع المنتدى) بما في ذلك SQL هو هدف جيد لموقع PHP. اعتاد موقع الويب القديم على القيام بذلك.