توی بحث وب، بهینه سازی یکی از ضروریاته چون سایت بازدیدکننده همزمان داره و ازطرفی مصرف ترافیک و پردازنده توی هاستهای اشتراکی خیلی با وسواس انجام میشه. چند وقت پیش یک نفر بهم پیام داد که از هاستشون اخطار دادن داری بیش از حد از منابع استفاده میکنی. بعد که کدش رو بررسی کردیم، با همین نکات ریزی که بنظر شما ارزشش رو نداره آدم وقت صرفشون کنه، توی هر درخواست حدود 50 مگابایت در مصرف حافظه صرفه جویی شد و با بررسی که تیم پشتیبانی هاست انجام دادن، لود CPU هم حدود 5 درصد کاهش داشت و تعداد اتصالات باز (همزمان) به MySQL هم در هر درخواست و از اونجا که یه سایت خبری بود و بازدیدکننده همزمان زیادی داشت، فشاری که به سرور میاورد توی یک بازه زمانی مشخص، چیزی حدود 90٪ کاهش پیدا کرد (مثلاً اگه توی یه بازه زمانی خاص، 50٪ پردازنده رو درگیر میکرد، این رقم به 5 درصد رسیده بود).
رتبه موضوع:
|
برنامه نویسی بهتر و بهینه تر PHP
|
|
13-07-1394، 01:52 ب.ظ
بله انصافا این بحث خیلی مهمه تو وب.
با رعایت مسائلی مثل gzip,server cache,leverage browser caching, کم کردن تعداد request و combine کردن فایل ها در حد ممکن و optimize تصاویر و کدنویسی درست توی هزینه ها خیلی میشه صرف جویی کرد. اشپیلن جان الان این بحث smart update که گوگل پلی گذاشته واسه همینه! کاربران به جای دانلود 15 مگ فرض کن 3 مگ دانلود میکنند. این واسه کاربرا خیلی تاثیر نمیذاره(با اینترنت نامحدودشون) ولی واسه گوگل پهنای باندش خیلی خیلی صرفه جویی میشه! هرچند روی دستگاه موبایل کاربر کمی زمان نیازه تا فایل نصبی جدید تولید بشه ولی چون خیلی محصوص نیست ارزششو داره. یکی از دوستان یه سایت داشت با جوملا بود وقتی بازدیدش یکم زیاد میشد صدای پشتیبان هاست در می اومد و در آخر صفحه مورد نظر رو بلاک میکردن!! ولی هیچ کردوم از سایت هایی که من نوشتم اینطوری نشدن! چون همه چیز رو سعی کردم رعایت کنم و سایت سبک باشه. الان طرف مجبور شده یه سرور اختصاصی بگیره! vps هم جوابگو نبود! این جوملا هم همش join میزنه! تشکر شده توسط: Alireza , mahdirabbani
 (13-07-1394، 09:29 ق.ظ)ADMIN نوشته: توی بحث وب، بهینه سازی یکی از ضروریاته چون سایت بازدیدکننده همزمان داره و ازطرفی مصرف ترافیک و پردازنده توی هاستهای اشتراکی خیلی با وسواس انجام میشه.خب من میگم امنیت هم از ضروریاته! چون سایت با کاربران زیادی سر و کار داره در محیط بی در و پیکر اینترنته امنیت کاربران زیادی دربین هست مسئولیت وجود داره نسبت به امنیت و اطلاعات کاربران و هکرها امکان و انگیزهء خیلی بیشتری برای حمله دارن. ولی واقعا چه حد چه چیزهایی کجا تحت چه شرایطی. اینه که مهمه! شما نمیای همه نوع الگوریتم امنیتی همه درجه ای رو و همه جزییات کم اهمیتی رو هرجایی در هر شرایطی بکار ببری. غیر از اینه؟ چرا؟ چون صرف نمیکنه. اینو خودت چندبار تاحالا گفتی. چون همین امنیت به پرفورمنس هم خدشه وارد میکنه. گذشته از افزایش چشمگیر حجم و پیچیدگی برنامه. عملا چیزی که وجود داره یک تعادل و tradeoff ها هستن. هنر برنامه نویسی خردمندانه اینه که این تعادل ها و tradeoff ها رو درست و بهینه تشخیص بده و پیاده کنه. یجا میبینه فلان مسئله در امنیت جزیی محسوب میشه یا برای اون سایت اون شرایط اون سطح امنیت اون اهمیت چندان اهمیت نداره، و بجاش پرفورمنس رو ترجیح میده، اون ویژگی رو پیاده سازی نمیکنه، یجا برعکس میبینه مورد درشت و مهمی هست، میاد کلی از پرفورمنس هم هزینه میکنه بخاطر امنیت. مثلا همین https از http به مراتب کندتر و سنگین تره، ولی سایتهای معروف و حرفه ای بخاطر امنیت ازش استفاده میکنن. اگر بهینه سازی مهمتر باشه که نباید این کار رو بکنن! مهندس کلی گویی و مبهم گویی کاری نداره و درواقع چیزی رو هم ثابت نمیکنه محتوای مشخصی نداره. یه حرفه ای باید اینو بدونه و از کلی گویی و مبهم گویی و اینکه کلی چیز ریز و درشت و کم و بیش مختلف و متفاوت رو توی یک کاسه بریزه و با هم مخلوط کنه تحویل بده، پرهیز کنه. جزء به جزء مورد به مورد شرایط به شرایط هرچیزی جداگانه باید تحلیل و ارزیابی بشه فرق میکنه. نقل قول:چند وقت پیش یک نفر بهم پیام داد که از هاستشون اخطار دادن داری بیش از حد از منابع استفاده میکنی. بعد که کدش رو بررسی کردیم، با همین نکات ریزی که بنظر شما ارزشش رو نداره آدم وقت صرفشون کنه، توی هر درخواست حدود 50 مگابایت در مصرف حافظه صرفه جویی شد و با بررسی که تیم پشتیبانی هاست انجام دادن، لود CPU هم حدود 5 درصد کاهش داشت و تعداد اتصالات باز (همزمان) به MySQL هم در هر درخواست و از اونجا که یه سایت خبری بود و بازدیدکننده همزمان زیادی داشت، فشاری که به سرور میاورد توی یک بازه زمانی مشخص، چیزی حدود 90٪ کاهش پیدا کرد (مثلاً اگه توی یه بازه زمانی خاص، 50٪ پردازنده رو درگیر میکرد، این رقم به 5 درصد رسیده بود).بازهم حرفای شما بنظر من کلی گویی و مبهم گویی و اغراقه. منکه نمیتونم باور کنم! دلیلی نداره! باید دقیقا دید تغییرات چی بوده، کدوماش چقدر تاثیر داشتن. شاید bottleneck ها موارد معدودی جاهای محدودی بودن، حالا این وسط کلی چیزا رو تغییر دادید همه چیز رو که بنظرتون میرسیده بهینه سازی کردید خب این وسط اون bottleneck ها و بهرصورت موارد درشت که تاثیر اصلی رو داشتن هم درست شدن، ولی شما سهم تغییرات و بهینه سازیهای دیگر رو هم مشابه فرض میکنی! از کجا میدونی از کجا مطمئنی؟ بنظر من بطور عادی عمرا بهینه سازیهای خیلی جزیی در سطح کدنویسی، مثل اینکه ما دوتا متغییر توی رشته بذاریم یا نذاریم، از کدوم تابع مشابه استفاده کنیم، نه مشکلی ایجاد میکنن و نه بهینه کردنشون چنین تاثیرات بزرگی ایجاد میکنه. البته میگم که بطور عادی، یعنی در 95% موارد. در 5% بله ممکنه بعلت شرایط خاصی این قضیه کم و بیش تغییر کنه. فرض کن مثلا شما وقتی رشتهء معمولی داری با چندتا متغییر معمولی، این عمرا مشکل ایجاد نمیکنه، حالا اگر توی یک حلقه با تکرار بالا باشه شاید، اونم تازه زیاد محتمل نمیدونم، ولی حالا فرض کن رشته اگر بزرگ و پیچیده باشه اگر محتوای متغییرها حجیم باشن و خلاصه شرایط غیرمعمول باشه، اونوقت نتایج هم ممکنه دیگه معمولی نباشه و روی پرفورمنس تاثیر خیلی بیشتری داشته باشه، چون این امکانات برای چنین استفاده های غیرعادی طراحی و پیشبینی و شاید حتی تست درستی نشدن بهینه نیستن بنابراین ممکنه پرفورمنس از یه حدی به بعد به شدت افت بکنه. ولی چه وقت در چند درصد کدها ما چنین شرایطی داریم که رشته ها و متغییرهای درج شده در اونا واقعا حجیم و پیچیده باشن؟ معلومه که کمه. هست، ولی کم. وقتی هم هست آدم خودش تشخیص میده چون واضحه غیرعادیه. خیال میکنی من حواسم به این چیزا نیست؟ من بخوام بهینه سازی کنم چیزهایی به ذهنم میرسه که همین افرادی که دم از بهینه سازی میزنن تاحالا به ذهنشون نرسیده! پس مورد رو باید دقیقا دید بررسی کرد تحلیل و تست کرد که چی بوده چیا رو تغییر دادن بهینه سازی کردن کجاها رو، و هرکدام چقدر میتونستن سهم داشته بوده باشن. مورد به مورد جزء به جزء کد به کد فرق میکنه. شما همه چیز رو با هم قاطی نکن. ارتباط شبکه ای، IO، پهنای باند، با پردازش عادی و چیزی که فقط در کدها در برنامه در CPU و RAM وجود داره و اتفاق میفته فرق میکنه، خروجی به مرورگر و بحث بهینه سازی اونم یه بحث دیگس. اون خروجی مثلا ممکنه توی سرور هم بافر بشه قبل از ارسال، و روی RAM ای که برنامه مصرف میکنه تاثیر بذاره روی منابعی که سایت شما مصرف میکنه تاثیر قابل توجه بذاره. این خروجی برای ارسال، خودش پردازش و دنگ و فنگ اضافه داره. ولی چیزی که فقط در سطح PHP دوتا کد و مقدار و متغییر عادی هست دوتا پردازش محلی معمولی، اینا تقریبا هیچی نیست! کسی که ادعا میکنه یه بهینه سازی جزیی درحد نمیدونم فرق ++$i و $i++ و یا درج چندتا متغییر معمولی توی رشته های معمولی (که حجم و پیچیدگی کمی دارن)، میتونه تفاوت محسوس در کارایی برنامه بذاره، باید با منبع و سند روشن و معتبر، یا با تست و اثبات عملی با بنچمارک در شرایط واقعی ثابت کنه! چون این حرف اصلا معقول نیست بعیده همچین چیزی! اینطور چیزها در برنامه ها اینقدر سهم ناچیزی از کل منابع مصرف شده توسط برنامه دارن که بحساب نمیان هرچی بهینه کنی به صفر هم که برسونی بازم تاثیرش یا اصلا دیده نمیشه یا به سختی دیده میشه. این چیزا بسیار بعیده در 99% برنامه ها علت اصلی مشکل پرفورمنس باشن. البته من باز تاکید میکنم که منظورم در شرایط معمولی در کدهای معمولی و متداول هست، نه مثلا یه چیزی رو بذاری توی حلقهء یک میلیون! و توی یک برنامهء معمولی که دارای بخشهای متداول دیگه هم هست باید این مسئله رو عملا ارزیابی کرد. نه اینکه شما بیای یه برنامه بنویسی که کلا از همین چندتا دستور محدود و ساده تشکیل شده و بعد اینا رو بهینه کنی بگی دیدی پرفورمنس نمیدونم مثلا 30% رفت بالا! چون توی یه برنامهء واقعی خیلی پردازشهای بزرگتر و بیشتر وجود دارن که در نتیجه این موارد جزیی درمقابل اونا بحساب نمیان و سهم خیلی کمی از کل پرفورمنس برنامه دارن. (13-07-1394، 01:52 ب.ظ)محسن نوری نوشته: بله انصافا این بحث خیلی مهمه تو وب. دوست عزیز اینا که میگی همشون موارد دیگه هست که مورد ایراد و بحث بنده نبودن. من دارم از یکسری بهینه سازیهای خیلی جزیی در سطح کدنویسی روتین صحبت میکنم. توی همون جوملا هم مطمئن باش سنگین بودن و مشکلش بخاطر این موارد جزیی نیست و اگر تمام این موارد جزیی رو به بهترین شکل هم بهینه سازی کنن، فکر نمیکنم بتونه بیشتر از چند درصد پرفورمنس رو افزایش بده! شاید مثلا 5% سریعتر بشه منابع کمتری مصرف کنه. البته اگر از قبل اینطور چیزها درش بهینه سازی نشده باشه. اینطور سنگینی ها از چیزهای به مراتب روشن تر و بزرگتری حاصل میشن. نه اینکه نمیدونم ++ رو قبل از متغییر گذاشتی یا بعدش! این مسخرس! همچین چیزهای جزیی اگر باعث کند شدن مشکل ساز برنامه ها بشن، پس دیگه فاتحه برنامه نویسی رو باید خوند، و باید PHP رو هم ول کرد رفت با سی برنامه نوشت! خود PHP پشت پرده داره برای همون تک دستورهای به اصطلاح بهینه که شما مینویسید کلی دستور و پردازش اضافه تر اجرا میکنه (به نسبت زبانهای سطح پایین تر مثل سی)، و اگر قرار بود این جزییات این پردازشهای پایه واقعا اینقدر مهم و تاثیرگذار باشن، PHP خودش اونقدر کند و سنگین میشد که کسی ازش استفاده نمیکرد، و الان همه از سی استفاده میکردن. امکاناتی که زبانهای سطح بالا پیاده میکنن چیزهایی هست که در کل پردازشهایی که تحمیل میکنن قابل تحمله، و این پردازشهای قابل تحمل از بهینه سازیهای جزیی که بعضی ها ازش دم میزنن به مراتب بیشتر هستن! اونوقت چطور همین چیزهای جزیی میتونه توی برنامه ها فرق مشکل دار و بدون مشکل رو تعیین کنه؟ یعنی از قبل دستورات PHP اینقدر کند اینقدر سنگین و لب مرز بودن که حالا چنین تغییرات جزیی بتونه برنامهء آدم رو اینقدر تحت تاثیر عملی قرار بده؟! اینا همش یک مشت ادعا و حرف و اغراق بی پایه است! من خودم قبل از PHP کلی سی کار کردم میدونم داستان پشت پرده چیه و چیزها ماهیتا چطور عمل میکنن توی پرفورمنس حدودا چقدر میتونن سهم داشته باشن و تفاوت ایجاد کنن. البته استثناء و شرایط خاص همیشه میتونه پیش بیاد، اینو بارها خودم گفتم، ولی شرایط خاص خب شرایط خاص و اغلب قابل تشخیص و پیشبینی و پیشگیری هم هست. و اکثر اوقات ما با شرایط غیرخاص سر و کار داریم. اینطور نیست که شرایط خاص اکثریت باشن. در اکثر برنامه ها اینطور نیست. نقل قول:چون همه چیز رو سعی کردم رعایت کنم و سایت سبک باشه.بله لابد همه چیز رو رعایت کردی. ولی برای من روشنه شک چندانی ندارم که سهم بعضی چیزها از چیزهای دیگر خیلی بیشتره در افزایش پرفورمنس. این اشتباهه که ما چون همه چیز رو از جزیی ترین تا بزرگترین و کلی ترین ها بهینه کردیم فکر کنیم سهم همهء اینها در افزایش پرفورمنس برابر یا حتی نزدیک هم بوده. یوقت میبینی 90% افزایش سرعت برنامهء شما فقط از 10% موارد و انواع بهینه سازی حاصل میشه. این مسئلهء عجیب و غیرقابل توجیهی نیست؛ به هیچ وجه ناشناخته نیست! افراد با تجربه و منابع معتبر متعددی دارن اینو میگن من متن و ترجمه ها و منابعش رو گذاشتم براتون. حالا چون شما همه چیز رو رعایت کردی همه سطح و جزییات رو بهینه کردی فکر میکنی اگر چیزهایی خیلی جزیی رو هم بهینه نمیکردی ممکن بود برنامت مشکل پرفورمنس پیدا کنه، درصورتیکه اینطور تصورات پایه درستی نداره و فقط یک حدس و تصوره که اگر خوب و مستند و مستدل فکر کنیم دلیلی نداره درست باشه. مثل اینکه شما مریضی چند نوع غذا و دارو و دستورالعمل رو رعایت میکنی خوب میشی، آیا دلیل میشه که همهء اون غذاها و داروها و کارهایی که کردی برای بهبود شما لازم بودن؟ نه بسادگی ممکنه فقط معدودی از اونا بودن که شما رو خوب کردن و بقیه تاثیری نداشتن یا تاثیر ناچیزی داشتن. در عمل هیچکس تاحالا نتونسته چنین چیزی رو ثابت کنه که بهینه سازیهای خیلی جزیی در سطح کد، مثل اونایی که من اشاره کردم، سهم جدی در پرفورمنس برنامه داشته باشن. کی شما چطوری تونستی واقعا بفهمی مطمئن بشی ثابت کنی که سهم هر بهینه سازی در افزایش پرفورمنس واقعا چقدره؟ بعضیا رو میشه همینطور هم گرچه حدودی با ضریب اطمینان خوبی تشخیص داد، ولی بعضی دیگر هستن که تشخیص اونا به این راحتی نیست تست و تحلیل های جامع در شرایط واقعی نیاز داره. شاید خیلی از بهینه سازیهای جزیی باشه که اگر بفهمی بهت ثابت بشه واقعا چقدر در افزایش پرفورمنس تقریبا تمام برنامه ها نقش دارن، اونوقت بگی عجب کار بیهوده ای میکردیم چقدر روی این چیزهای بیخودی و تقریبا بی تاثیر مصر بودیم به خودمون زحمت میدادیم!
14-07-1394، 07:47 ق.ظ
من نمیدونم چه اصراری داری اشپیلن که ثابت کنی در این مورد درست میگی؟ بهرحال بهینه سازی مسئله مهمیه و توی وب هم اهمیتش بیشتر میشه. مثلاً وقتی با بنچمارک و تست واقعی ثابت میشه گرفتن تعداد عناصر آرایه قبل از حلقه بجای داخل بخش Condition حلقه رو نزدیک به 40 برابر سریعتر میکنه و مثلاً foreach توی آرایه های چند بعدی خیلی سریعتره، چرا نباید اهمیت رعایت این موارد رو گوشزد کنیم؟ درسته که بخش مهمی از بهینه سازی، خود الگوریتمه ولی نحوه اجرای الگوریتم هم مهمه.
شما که همیشه دنبال مستدل و با سند و مدرک حرف زدن بودی، چرا الان رو هوا داری میگی اینا مهم نیست؟ برو تست کن روی داده های سنگین ببین چقدر تأثیر دارن این موارد. تیم توسعه فیسبوک مگه مریض بود بره یه زبان دیگه بنویسه و چیزی نزدیک به 9 میلیون خط کد بنویسه واسه کاری که بقول خود زاکربرگ توی کنفرانس مطبوعاتی، اگه قرار بود بهینه ننویسن و فقط کار کنه، دو سوم این خطوط اضافه بود؟! اینجا بحث بحث وبه و درخواستهای همزمان و منابع محدود. پس هر یک کیلوبایت هم در جای خودش اهمیت پیدا میکنه. شما دوست نداری، تو پروژه های خودت رعایت نکن! بحث PHP و C هم فرق میکنه. شما اگه تونستی توی ++C به همون راحتی PHP شئ گرا بنویسی برو بنویس. مقاومت دربرابر کدنویسی بهینه از اونجا ناشی میشه که یه عمر عادت کردیم هر دم بیلی برنامه بنویسیم و الان سختمونه استایل کدنویسیمون رو درست کنیم. این تاپیک ایجاد شده تا کسانی که میخوان تازه وارد این عرصه بشن، از همون اول روش درست رو یاد بگیرن. کسانی هم که تنبل نیستن و از تغییر نمیترسن هم روش کدنویسیشون رو اصلاح کنن. وقتی میشه با رعایت این اصول، یه وب سایت رو روی یه هاست اشتراکی بالا آورد، چرا رعایت نکنیم و مجبور بشیم پول سرور مجازی یا اختصاصی بدیم؟ چرا همش سنگینی کار رو باید گردن تجهیزات بندازیم؟ فهمیدنش واقعاً سخت نیست!!!
14-07-1394، 08:01 ق.ظ
(13-07-1394، 09:26 ب.ظ)Eshpilen نوشته: مهندس کلی گویی و مبهم گویی کاری نداره و درواقع چیزی رو هم ثابت نمیکنه محتوای مشخصی نداره. یه حرفه ای باید اینو بدونه و از کلی گویی و مبهم گویی و اینکه کلی چیز ریز و درشت و کم و بیش مختلف و متفاوت رو توی یک کاسه بریزه و با هم مخلوط کنه تحویل بده، پرهیز کنه.بعد از نزدیک به 7 سال تخصصی روی PHP وقت گذاشتن، دیگه اینقدر میفهمم که گلوگاههای برنامه کجا بودن. برای هر بخش از کارمون Unit Test های جداگانه نوشته بودیم که با بنچمارک گرفتن مشخص شد اینموارد چقدر توی بهینگی تأثیر داشتن. شما از کجا اینقدر با اطمینان میگی که بنچمارک نگرفتیم؟ فکر میکنم شما که داری میگی «بعید میدونم خیلی تأثیر داشته باشه» و «احتمال میدم تأثیرش کم باشه» داری کلی گویی میکنی و مبهم حرف میزنی. برو تست کن تا بهت ثابت بشه چقدر تأثیر داره. سایت phpbench رو بررسی کن ببین با بنچمارک گذاشته یا گفته حدس میزنم بهتر باشه؟! حتماً که نباید جلو چشم خودت تست و اجرا کنن تا باور کنی!!! (14-07-1394، 07:47 ق.ظ)ADMIN نوشته: بهرحال بهینه سازی مسئله مهمیه و توی وب هم اهمیتش بیشتر میشه.خب مگه من گفتم مهم نیست؟ من یه موارد خاص و بهینه سازیهای خیلی جزیی اونایی که میدونم کلا درصد بسیار کوچکی از کل پرفورمنس برنامه رو تشکیل میدن میگم، شما میای یه چیزای دیگه که خیلی فرق میکنن خیلی درشت تر هستن رو میگی که من اصلا با اونا کار نداشتم و ندارم. یا میای کلی گویی و مبهم گویی میکنی همه چیز رو میریزی توی یک کاسه هم میزنی میگی ایناهاش اینه! نقل قول:مثلاً وقتی با بنچمارک و تست واقعی ثابت میشه گرفتن تعداد عناصر آرایه قبل از حلقه بجای داخل بخش Condition حلقه رو نزدیک به 40 برابر سریعتر میکنه و مثلاً foreach توی آرایه های چند بعدی خیلی سریعتره، چرا نباید اهمیت رعایت این موارد رو گوشزد کنیم؟خب این یکی انصافا مورد قابل توجه تری هست از بین چند مورد بهینه سازیهای جزیی مطرح شده. ولی حتی اینم حرف من اینه که دلیل نمیشه بگی چون 40 برابر سریعتره پس همیشه باید بهینه سازی بشه! اینجا شما فقط بخشی از واقعیت رو دیدی، یعنی فقط اون 40 برابر رو دیدی! هرکس فقط عدد 40 رو ببینه میگه اوه چقدر زیاد پس حتما اگر اینو رعایت کنم پرفورمنس برنامم خیلی بیشتر میشه، درحالیکه در واقعیت اینطور نیست. 40 برابر یک میلیونیوم میشه 40 میلیونیوم که هنوزم عدد ناچیزی هست. 40 برابر یک صدم درصد میشه 4 دهم درصد، که هنوزم درصد ناچیزی هست. مهندس باور کن خیلی از مردم در ریاضی اینقدر ضعیف هستن که حتی چنین محاسبات رو هم نمیتونن بصورت ذهنی درست انجام بدن خیلی وقتا اشتباه میکنن من بارها دیدم. سوادها واقعا پایینه! حتی بین افرادی که مثلا برنامه نویس هستن! حرف من اینه که اینکه بخوایم ببینیم چیزی در عمل تاثیر قابل توجه میذاره مهم هست ارزش پرداختن و زحمت دادن به خود در کدنویسی رو داره فقط به این نیست که چند برابر سریعتره، بلکه به اینه که چه کسری از پرفورمنس برنامه توی این چیزا صرف میشه. که من دارم میگم درمورد اینطور بهینه سازیهای جزیی این کسر در اکثر برنامه ها خیلی کوچکه. بنظر من برای یه حلقهء عادی و وقتی شرایط خاص نداریم، هیچ لزومی نداره به خودمون زحمت بدیم چنین بهینه سازی ای بکنیم، چون در عمل تقریبا هیچ تاثیری نداره. ولی حالا اگر تعداد تکرار حلقه واقعا زیاد بود، اگر شرایط خاصی بود بهرحال، که سهمش در پردازش قابل توجه میشد، خب بهینه سازی میکنیم. اگر شما منظورت اون موارد هست من مخالفتی ندارم، ولی بهرحال حتی در این موارد هم اغلب تصوری که توی ذهنها هست تخمین و حدسهایی که زده میشه بیش از حدی هست که در واقعیت واقعا وجود داره. نقل قول:شما که همیشه دنبال مستدل و با سند و مدرک حرف زدن بودی، چرا الان رو هوا داری میگی اینا مهم نیست؟ برو تست کن روی داده های سنگین ببین چقدر تأثیر دارن این موارد.خوبه پس تا اینجا شما هم با من توافق داری که این مسائل درموارد معمولی و داده های کوچک تاثیر عملی چندانی در واقعیت نداره! پس شرط داده های سنگین رو اضافه کردی. که البته اینم تاحدی کلی و مبهم هست چیز دقیق و ثابت شده و قابل محاسبه ای نیست فرمول و معیار و عددی به همراه نداره، ولی قابل درک و پذیرش هست. باز هر مورد باید دید و ارزیابی کرد یا حتی تست عملی کرد که واقعا چقدر ممکنه تاثیر در پرفورمنس دیده بشه. حرف اینه که بهینه سازیهای خیلی جزیی جزو استثنائات هستن، نه قواعد کلی که همیشه باید رعایت کرد! ما در 80% کدهای برنامه شرایطی نداریم که این موارد تاثیر مشهودی روی پرفورمنس کلی برنامه داشته باشن، ولی در 20% هم شاید داشته باشیم. از برنامه به برنامه این درصدها میتونن کم و بیش متفاوت باشن البته. استثناء رو در موارد استثناء رعایت میکنن اهمیت میدن، نه همیشه. نقل قول:تیم توسعه فیسبوک مگه مریض بود بره یه زبان دیگه بنویسه و چیزی نزدیک به 9 میلیون خط کد بنویسه واسه کاری که بقول خود زاکربرگ توی کنفرانس مطبوعاتی، اگه قرار بود بهینه ننویسن و فقط کار کنه، دو سوم این خطوط اضافه بود؟!ببین مهندس باز داری یه مطلب بی ربطی رو قاطی میکنی! این قضیه فیسبوک چه ربطی داره به موارد و کارهای ما آخه؟ فیسبوک شرایطش خاصه در مقیاسی کار میکنه که خیلی شرایط خاص پیش اومده و میاد براشون و خواهد آمد که برای مقیاسهای معمول برای من و شما تقریبا هیچوقت دیده نمیشه یا مسئلهء جدی ای نیست میشه به روشهای ساده تر و کم هزینه تری هم حلش کرد. فیسبوک خیلی کارها کرده خیلی چیزهای جدید فناوریهایی برای مقیاسهای بسیار بزرگ درست کرده که اینا رو شما توی سایتهای عادی نمیبینی و البته اکثرا نیاز آنچنانی هم نیست. درحالیکه خود فیسبوک اگر اینا رو نداشت تاحالا یا خوابیده بود یا نیاز داشت کلی سخت افزار و تشکیلات اضافه بخره کلی هزینه اضافی بکنه. تازه اینا هم اکثرا دنبال راهکارهای سطوح دیگر میرن، میرن کارهای اساسی تر و کلی تری میکنن، مثلا کامپایلر مینویسن PHP رو تبدیل به سی++ کنه و غیره بقول شما زبان جدیدی درست میکنن، نه اینکه بیان در سطح کدنویسی عادی یکسری جزییات رو که در عمل 1% تاثیر میذارن و مشکلی رو حل نمیکنن رعایت کنن. یه راهکارهایی پیاده میکنن که بعدا قراره بارها در هر برنامه ای دیگه بصورت خودکار خودش عمل کنه نیاز به صرف وقت و انرژی دوباره و دوباره در کدنویسی و برای برنامه نویسان سطوح بالاتر نداره اونقدر، و بهرحال اینا برنامه های سیستمی برنامه های سرویس دهنده هستن، نه برنامه های سطح بالا و اپلیکیشن های سطح کاربر. نقل قول:اینجا بحث بحث وبه و درخواستهای همزمان و منابع محدود. پس هر یک کیلوبایت هم در جای خودش اهمیت پیدا میکنه. شما دوست نداری، تو پروژه های خودت رعایت نکن!یک کیلوبایت کم و بیشتر فکر نمیکنم برای بیشتر سایتهای معمولی برنامه های معمولی تاثیری داشته باشه. مگه همزمان چندتا کاربر دارن شما ضربدر اون کن ببین چقدر میشه آیا چند مگابایت و حتی چند ده مگابایت RAM بیشتر و کمتر در کل امروزه روز برای بیشتر کاربردها اهمیتی داره مشکلی ایجاد میکنه؟ با فیسبوک مقایسه نکن لطفا! گفتم که شما همه چیز رو با هم قاطی میکنی شرایط خاص و استثناها رو نمیشه و نباید کلیت داد. فناوریهایی که فیسبوک استفاده میکنه الان روش بیشتر هاستها و سایتها نیست، اگر لازم بود خیلی مهم بود چرا پس نیست؟ شاید اگر بذارن برای بعضیا حداقل مفید و قابل استفاده باشه، ولی اصل استفاده و اهمیتش برای همون مقیاس برای همون امثال فیسبوک هست یا سایتهایی که بهرحال در مقیاس بزرگی باشن. نقل قول:بحث PHP و C هم فرق میکنه. شما اگه تونستی توی ++C به همون راحتی PHP شئ گرا بنویسی برو بنویس. مقاومت دربرابر کدنویسی بهینه از اونجا ناشی میشه که یه عمر عادت کردیم هر دم بیلی برنامه بنویسیم و الان سختمونه استایل کدنویسیمون رو درست کنیم. این تاپیک ایجاد شده تا کسانی که میخوان تازه وارد این عرصه بشن، از همون اول روش درست رو یاد بگیرن. کسانی هم که تنبل نیستن و از تغییر نمیترسن هم روش کدنویسیشون رو اصلاح کنن.خب منم همینو میگم دیگه! چون برنامه نویسی در سی و سی++ سخت تر حجیم تر و زمانبرتر از PHP هست، و طبیعتا میتونه به باگهای بیشتری هم منجر بشه، پس اون پرفورمنس افزوده رو بی خیال میشیم، چون ارزش وقت و انرژی برنامه نویس و پایداری و کیفیت و امنیت برنامه بیشتر از حتی چند برابر سرعت افزوده ای هست که با سی میشه بدست آورد. غیر از اینه؟ نقل قول:وقتی میشه با رعایت این اصول، یه وب سایت رو روی یه هاست اشتراکی بالا آورد، چرا رعایت نکنیم و مجبور بشیم پول سرور مجازی یا اختصاصی بدیم؟ چرا همش سنگینی کار رو باید گردن تجهیزات بندازیم؟ فهمیدنش واقعاً سخت نیست!!!کدوم اصول؟ شما با اون بهینه سازیهای جزیی عمرا نمیتونید یه چیزی رو اونقدری سبک کنید که روی هاست اشتراکی که قبلا بالا نمیامده حالا خوب کار کنه! مشکل جای دیگس دوست عزیز اگر برنامه سنگینه یا واقعا نیاز داره سنگین باشه یا اینکه مشکل بهینه نبودن و الگوریتم های اشتباه و اینا توی چیزهای به مراتب بزرگتری هست، نه اینکه ++ رو قبل متغییر گذاشتی یا بعدش و خلاصه اینطور چیزا! مثلا میگن جوملا سنگینه. خب بیاید این چند مورد بهینه سازیهای خیلی جزیی رو که من در این تاپیک بهشون گیر دادم توی خط به خط جوملا درست کنید، بعد ببینید پرفورمنس چقدر میره بالا! آیا مشکل سنگینی جوملا به این خاطر حل میشه مشکلش بخاطر این موارد جزیی بوده؟ معلومه که نه! اگر میشد مشکل سنگینی جوملا رو با این چیزهای جزیی حل کرد که خب تاحالا یکی انجامش داده بود و جوملا رو سریع کرده بودم. این کارها رو انجام میدی میای میبینی سرعتش فقط چند درصد زیادتر شده، که این مشکلی رو حل نمیکنه به هیچ وجه کافی نیست از اول ارزش انجام دادن هم نداشت! غیر از اینه؟
14-07-1394، 10:24 ق.ظ
(14-07-1394، 08:01 ق.ظ)ADMIN نوشته: بعد از نزدیک به 7 سال تخصصی روی PHP وقت گذاشتن، دیگه اینقدر میفهمم که گلوگاههای برنامه کجا بودن.خب کجا بودن؟ آیا چندتا حلقهء معمولی با داده ها و متغییرهای خیلی معمولی که روتین توی اکثر الگوریتم ها هست، باعث مشکل پرفورمنس برنامهء شما شده بود؟ شما میگی آرایه های چند بعدی، داده های حجیم، ...، خب اینا همش شرایط خاص هست. حرف منم همینه که در شرایط خاص هست که تاثیر بهینه سازیهای اینقدر جزیی میتونه قابل توجه بشه. شما میای چیزایی رو مطرح میکنی طوری که من ادعا کردم که من درواقع هیچوقت ادعا نکردم! میای میگی اصول! همه چیز رو میریزی توی یه کاسه مخلوط میکنی بهش میگی اصول! درحالیکه این درست نیست و مسائل بیش از حد کلی و مطلق و ناقص هستن اینطوری. من درواقع بحث بهینه سازی رو تکمیل میکنم و چیزهایی هم که میگم اتفاقا چیزهای مهمی هستن چون خیلی افراد مبتدی و کم سواد نمیدونن درک نمیکنن. چیزهایی که میگم نقل قولها و منابع معتبر پشتش هست. حرف من به تنهایی نیست! طرف وقتی میگه 80% پرفورمنس برنامه از 20% کد حاصل میشه، این واقعیته که تجربه و عمل ثابت کرده، و دونستن و درک این مهمه در عمل میشه ازش استفاده کرد و از اتلاف کلی وقت و انرژی افزوده و پیچیده شدن و باگهای برنامه ها بخاطر بهینه سازیهای افراطی و غیرضروری جلوگیری کرد. نقل قول:فکر میکنم شما که داری میگی «بعید میدونم خیلی تأثیر داشته باشه» و «احتمال میدم تأثیرش کم باشه» داری کلی گویی میکنی و مبهم حرف میزنی. برو تست کن تا بهت ثابت بشه چقدر تأثیر داره. سایت phpbench رو بررسی کن ببین با بنچمارک گذاشته یا گفته حدس میزنم بهتر باشه؟! حتماً که نباید جلو چشم خودت تست و اجرا کنن تا باور کنی!!!گفتم که این به تنهایی تعیین کنندهء اصول و انتخاب های ما نیست که سرعت فلان روش 40 برابر فلان روشه! توی سایت phpbench هم مگه غیر از اینطور چیزا چیزی گذاشته؟ من میگم این اطلاعات ناقصه، در عمل فرمول محاسبهء کلی و تصمیم اهمیت و سهم هرچیزی و اینکه ارزش پرداختن داره یا نه، پارامترهای دیگری هم داره که باید اونا رو هم دونست ارزیابی کرد و بحساب آورد توی فرمول گذاشت و محاسبه کرد. آیا توی این سایتها نوشته اثبات عملی کرده تحقیق در شرایط واقعی کرده که در یک برنامهء معمولی بطور متوسط چند درصد پردازش و زمان کلی، توسط چنین کدها و جزییاتی صرف میشن؟ من دارم درست میگم، چون بر اساس تئوری بر اساس منابع و تایید متخصصان و دقیق صحبت میکنم، گرچه بصورت عملی با مثال و بنچمارک ثابت نکردم. اما شما از لحاظ تئوری و منبع و سند چیز خاصی ارائه نمیکنید فقط یکسری کلی گویی و مبهم گویی و مغطه میکنید و یکسری چیزهای بی ربط رو پیش میکشید که شرایط متفاوت شرایط خاص دارن اکثریت موارد نیستن، همه چیز رو میریزید توی یک کاسه مخلوط میکنید میگید همش مشابه است! شما که اینقدر ادعا میکنید چنین چیزی هست، خلاف منابع و قواعد علمیش، خب شما ثابت کنید! چرا من ثابت کنم چیزی رو که استدلال ها و منابع روشن تر و دقیقتر و معتبرتری نسبت به شما براش دارم؟ چرا این وظیفه و زحمت گردن من؟ شما که میگید میشه با بهینه سازیهای جزیی افزایش پرفورمنس زیادی داشت، خب برید مثلا جوملا رو با این کارها بهینه کنید ببینیم سرعتش چقدر میره بالا! بعید میدونم هرچی زور بزنید این افزایش سرعت از 5% بیشتر بشه! بازم تاکید میکنم که منظور من مواردی هست که قبلا گفتم و نه یکسری بهینه سازیهای دیگه بی ربطی که شما مطرح کردید! من دارم از موارد خیلی معمولی و جزیی و ساده ای صحبت میکنم مثل اینکه دوتا متغییر معمولی رو توی رشته های معمولی بذاری یا نه، اینکه ++ رو قبل از متغییر بذاری یا بعدش، اینکه یه حلقهء معمولی داری که حالا میخواد نهایت 100 دور اصلا گیریم 1000 دور بزنه و داره روی متغییرهای عادی داده های معمولی با حجم معمولی و محدودی کار میکنه آیا count رو مستقیم توی قسمت شرطش بذاریم یا نه. از چیزهای دیگه با من صحبت نکنید دیگه لطفا قاطی نکنید چون من هیچوقت اونا رو نگفتم! هرجا هم از بهینه سازیهای جزیی صحبت کردم گفتم بله شرایط خاص هم میتونه باشه که همون بهینه سازی جزیی خیلی موثرتر بشه.
14-07-1394، 10:32 ق.ظ
شما سایت همارشتن رو ببین (اگه نمیدونی چقدر سیستم بزرگیه و سایتش چقدر بازدید داره یه نگاه به بخش پروژه هاشون بنداز - کل پنجره های برج میلاد، یکی از نمونه کارهاشونه). این سایت رو خودم نوشتم. با رعایت همین اصولی که میگین، الان داره روی هاست اشتراکی کار میکنه. روزانه چند هزار بازدید داره و الان یه هفته است که روی هاست جدید بالا آوردیمش. سرعت بارگذاری و حجم اطلاعات و... رو که درنظر بگیرین، متوجه میشین که همین موارد جزئی توی پروژه های کوچک هم میتونه تأثیر خودش رو بگذاره. این استانداردهای بهینه سازی رو چهارتا برنامه نویس تازه کار در نیاوردن از خودشون که اینطوری اونها رو بی فایده میدونید. باز هم تأکید میکنم تا وقتی شخصاً بنچمارک نگرفتی و اختلاف سرعت رو ندیدی، دیگه این بحث رو ادامه نده بگذار تاپیک روال خودش رو طی کنه. تمامی پستهای غیرمرتبط با موضوع اصلی و بحثهای حاشیه ای تا 24 ساعت آینده حذف خواهد شد.
نقل قول:شما که میگید میشه با بهینه سازیهای جزیی افزایش پرفورمنس زیادی داشت، خب برید مثلا جوملا رو با این کارها بهینه کنید ببینیم سرعتش چقدر میره بالا! بعید میدونم هرچی زور بزنید این افزایش سرعت از 5% بیشتر بشه!من برای امتحان اومدم وردپرس رو (اونم نه همش، بخش UI کاربری رو فقط) با این روشها (و یکسری اصول شئ گرایی مثل استفاده از رابطها و...) بهینه سازی کردم و جالب بود که تعداد درخواستهای همزمانی که میتونست در واحد زمان جواب بده (و Fail نشه) توی تست برای 100 درخواست همزمان و اجرا به مدت 100 ثانیه، 40٪ رشد داشت. حالا باز بیا بگو کلی و مبهم دارم حرف میزنم. کلاً تخصصت همین دو کلمه است!
14-07-1394، 11:16 ق.ظ
(14-07-1394، 10:32 ق.ظ)ADMIN نوشته: با رعایت همین اصولی که میگین، الان داره روی هاست اشتراکی کار میکنه. روزانه چند هزار بازدید دارهروزی چند هزار بازدید که چیزی نیست! حتی برای هاست اشتراکی! شما که دیگه با اطلاع هستی میدونی تعداد بازدید همزمان با تعداد بازدید روزانه خیلی فرق میکنه. نقل قول:و الان یه هفته است که روی هاست جدید بالا آوردیمش. سرعت بارگذاری و حجم اطلاعات و... رو که درنظر بگیرین، متوجه میشین که همین موارد جزئی توی پروژه های کوچک هم میتونه تأثیر خودش رو بگذاره.ببخشید الان دقیقا سرعت بارگذاری و حجم اطلاعات چه ربطی به این داره که ++ رو قبل از متغییرها گذاشتید یا بعدش؟ گیریم کلا مثلا 200 تا هم ++ توی برنامه استفاده کرده باشید، غیر از اونایی که توی حلقه های با تکرار بالاست، بقیش توی افزایش پرفورمنس برنامه بنظر شما چند درصد تاثیر داشته؟ نقل قول:این استانداردهای بهینه سازی رو چهارتا برنامه نویس تازه کار در نیاوردن از خودشون که اینطوری اونها رو بی فایده میدونید.خب اون نقل قولها و منابعی هم که من گذاشتم کار چهارتا برنامه نویس تازه کار نیست! دوما که من هیچوقت با بهینه سازی بطور کلی مخالفت نکردم، بلکه با بهینه سازیهای خیلی جزیی در شرایط غیرخاص مخالفت کردم. نقل قول:من برای امتحان اومدم وردپرس رو (اونم نه همش، بخش UI کاربری رو فقط) با این روشها (و یکسری اصول شئ گرایی مثل استفاده از رابطها و...) بهینه سازی کردم و جالب بود که تعداد درخواستهای همزمانی که میتونست در واحد زمان جواب بده (و Fail نشه) توی تست برای 100 درخواست همزمان و اجرا به مدت 100 ثانیه، 40٪ رشد داشت. حالا باز بیا بگو کلی و مبهم دارم حرف میزنم. کلاً تخصصت همین دو کلمه است!خب بالاخره داری میگی و یکسری اصول شیء گرایی! پس یه چیزی قاطیش بوده و فقط بحث چند بهینه سازی خیلی جزیی نبوده. از کجا میدونید که سهم اون بهینه سازیهای جزیی در این 40% چند درصد بوده و چند درصدش مال اون تغییرات در شیء گرایی و ایناست؟
شما خودت مثال از وردپرس زدی همینطور فقط یک بخشش رو اونم احتمال سرسری با صرف وقت و انرژی محدودی بهینه سازی کردی، میگی 40% تاثیر داشته.
البته میگی بخش UI کاربری رو فقط، که باید دید دقیقا کدوم قسمت منظورتونه. آیا بخش پنل ادمین رو میگید؟ چون خیلی ممکنه فرق بکنه. و در کل باید دید اون بخش چه سهمی از ترافیک معمول وردپرس رو به خودش اختصاص میده. منظورم اینه شاید چون بخشی بوده که سهم کوچکی در کل ترافیک رو داره، برنامه نویسان وردپرس هم به بهینه سازی اون اهمیت کمی دادن. گذشته از تمام اینها، بهرحال درکل آیا وردپرس نرم افزار موفقی بوده و هست یا نه؟ مگر نه اینه که سالهاست بیشتر وبلاگ ها با وردپرس هستن؟ بعدم داریم میگیم وبلاگ. و اکثریت وبلاگ ها ترافیک سنگین (تعداد کاربران همزمان زیاد) ندارن. پس باید دید برای چه نرم افزاری چه شرایطی بهینه سازی میکنید، و اونقدری بهش اولویت بدید وقت و انرژی صرفش کنید که ارزشش رو داشته باشه در عمل بازدهی خوبی نتایج مثبت کافی داشته باشه، وگرنه خب میرید روی چیزهای دیگش بخشهای دیگه توسعه امکاناتش یا حتی نرم افزارهای دیگری کار میکنید! من خودم چند برنامه نوشتم تاحالا. اگر میخواستم روی هرکدامش کلی وقت و انرژی اضافه بذارم همه چیش رو با وسواس تا جزیی ترین چیزها بهینه سازی کنم، شاید چندتا از برنامه های دیگری رو که نوشتم هنوز ننوشته بودم، چون وقت و انرژی من روی بهینه سازی برنامه هایی کدهایی تلف شده بوده که هنوزم استفادهء زیادی و نیاز مبرمی به بهینه سازی برام ندارن! پس انتخاب من عاقلانه بوده. ضمن اینکه هروقت لازم شد میتونم اونی رو که واقعا نیاز میشه بهینه کنم. اونقدری هم کار سخت و زمانبری نیست، ولی بعضیا زیادی گندش میکنن! خود شما مگه وردپرس رو بهینه سازی نکردی؟ چقدر روش وقت گذاشتی؟ خیلی سخت بود؟ تازه شما که برنامه نویس وردپرس نبودید. برنامه نویسان خودش بهش احاطهء بیشتری دارن احتمالا خیلی راحتتر و سریعتر میتونن نقاط مشکل و بهینه سازیهای بزرگ رو پیدا و بهینه سازیش کنن. بنظر شما این بهتره که آدم چندتا برنامهء جالب و مفید دیگه بیشتر بنویسه، یا اینکه برنامه های کمتری رو از نظر پرفورمنس بهینه سازی کنه درحالیکه در دنیای واقعی هنوز ضرورت چندانی نداره؟
متاسفانه مهندس خودت دقت و رفتار حرفه ای نداری، بعد از حرفهای من میرنجی!
مثالش رو در تاپیک دیگه (کپچا) هم دیدیم که کاملا سطحی میخونی دقت نمیکنی و همینطور یه بند 10 تا پست زدی بر اساس فرضهای اشتباه و تصورات ذهنی خودت. مثلا مورد سالت که آخرش میگی حواست نبوده. اگر وقت نداری بخونی فعلا اینطوری روی هوا جواب ندی بهتره خب بذار سرفرصت دقیقتر بخون بیشتر بررسی کن. در خیلی چیزهایی دیگه هم درواقع من چیزی که میگم درست میگم دقیق میگم، اما دیگران خودشون میان برداشتهای اشتباه چیزهای بی ربطی میگن. مثلا من کی با بهینه سازی مخالفت کلی کردم گفتم تاثیری نداره؟ من روی جزییات خاصی منطق و روش و سیاست و تفکر خاصی که معیارهای روشن و خاص داره صحبت میکنم. حالا شاید یکی دو مورد هم من کم و بیش اشتباه کنم، اما عدم دقت و اشتباهات و چیزهای بی ربط و مغلطه های دیگران بیشتره. من میام یه چیزی میگم دیگران میان چیزی میگن مواردی مثال میزنن که درواقع ربطی نداره. من دقیق و جزیی صحبت میکنم نسبی حرف میزنم اونا بحثهای کلی و مطلق میکنن.
14-07-1394، 01:25 ب.ظ
نه منظورم از بخش کاربری، همون UI نمایش بیرونی سایت بود. اینجا هم صحبت اصلاً سر این نیست که حتماً توی همه جا باید این اصول رعایت بشه. داریم راهکارهایی که میتونه به پرفورمنس برنامه شما کمک زیادی بکنه رو اعلام میکنیم تا اگه به مشکل برخوردین، قبل از اینکه به فکر ارتقاء سخت افزاری و... بیفتین، یکم کدتون رو روتوش کنید.
درمورد سؤال آخر هم معتقدم اگه به این اصول عادت کنید، واقعاً اینقدر سخت و دست و پاگیر نیستن که سرعت کار شما رو کم کنن. در نهایت با رعایت این اصول، میشه برنامه های زیادی رو به شکل بهینه نوشت و کیفیت و کمیت رو در کنار هم داشت. چرخه حیات برنامه فقط تا فاز نوشتن و تحویل دادن نیست و پشتیبانی هم در کاره. یه کاری نکنید که توی پشتیبانی بخواین از برنامه نویسی توبه کنید!!! تشکر شده توسط:
این اخیر شما حرف خیلی معقول تری هست.
ولی بنظر من همچنان چیزهایی در این حد که ++ رو پشت متغییر بذاریم یا جلوش، در 99% برنامه ها هیچ تاثیر مشهودی در پرفورمنس ایجاد نمیکنه که بخوایم حتی فکرمون رو بهش مشغول کنیم. اون جاهای خاصی هم که شرایط خاص دارن میتونن تاثیرگذار باشن خب آدم تشخیص میده یا بعدا اگر بخواد بهینه کنه فهمیدن و اصلاح کردن اونا کار سختی نیست بنظرم. بعدم مطالبی که من میدم نقل قولها و منابعی که میذارم فقط به همین چندتا بهینه سازی ساده محدود نمیشه، بلکه درمورد بهینه سازیهای به مراتب پیچیده تر و بزرگتری هم هست. بهینه سازی زیاد به ذهن آدم میاد، هزاران نوع بهینه سازی هست و میشه تصور کرد، ولی همش که صرف نداره هرجایی لازم نیست! مثلا بارها تجربه خود منه در چند برنامه ای که نوشتم، یوقت میخوام یه فایلی رو دیتایی رو بخونم روش کاری انجام بدم دوباره سیو کنم خب PHP توابعی مثل file_get_contents و file_put_contents رو گذاشته برای راحتی، ولی میدونیم که این توابع روی تمام دیتا بصورت یکجا کار میکنن. یعنی مثلا فایلت اگر 500 کیلوبایت باشه، تمام 500 کیلوبایت یکجا توی RAM لود میشه. حالا ما خیلی وقتا میتونیم اون عملیات رو بصورت تکه تکه هم انجام بدیم (یا اصلا شاید فقط بخش کوچکی از اون رو نیاز داریم) لازم نیست حتما از اول تمام دیتا در حافظه لود شده باشه در متغییری همش موجود باشه، و میتونیم به کمک توابع فایل سطح پایین تر مثلا در هر زمان فقط بخشهایی رو که نیاز داریم بخونیم توی متغییرها ذخیره و روش کار کنیم، و به این شکل مصرف حافظه رو میشه 10 برابر هم کاهش داد، ولی از اون طرف باید دید از نظر CPU و زمان صرف شده چه داستانی هست آیا کمتر میشه یا بیشتر، این فکر نمیکنم از قبل چیز روشنی باشه براحتی بشه حدس زد و مطمئن بود! چون بهرحال ما داریم عملیات بیشتری رو در کد PHP مینویسیم کدهای بیشتری منطق بیشتری داریم (حلقه و تشکیلات خوندن و نوشتن بخش به بخش). پس بعضی وقتا باید حتی بین پارامترهای پرفورمنس اونی رو که بنظرمون مهمتر و میزانش بیشتره بیشتر تاثیر میذاره ترجیح بدیم انتخاب کنیم. مثلا باید ببینیم فشار روی سرور و محدودیت منابع ما بیشتر با اون 500 کیلوبایت مصرف RAM وابستگی داره یا محدودیت توان پردازش CPU و زمان برای ما مشکل جدیه. این فقط یه نمونه. میگم هزاران نوع بهینه سازی ممکن وجود دارن. گاهی چیزهای نسبتا ساده رو میشه به اسم بهینه سازی کلی پیچوند ناخوانا کرد و کد اضافه نوشت! و همهء این کارها رو میکنی اصلا از قبل نمیشه مطمئن بود معلوم نیست که در واقعیت برنامت بهش نیاز داشته یا چقدر به پرفورمنس کمک میکنه آیا ارزشش رو داره یا نه. بخاطر همینه که میگن بهینه سازی زودهنگام نکنید، میگن اول بنویسید راه بندازید بعد بهینه سازی کنید، یا اصلا تنها وقتی عملا مشکل پرفورمنس دیده شده اونوقت تنگه ها رو پیدا و بهینه کنید. چون از قبل نمیشه اینقدر پارامتر و پیچیدگی داره و از مورد به مورد و محیط به محیط تفاوت میکنه که حتی برنامه نویسان با تجربه هم ممکنه در این زمینه براحتی اشتباه کن. من خودم پس کار ندارم اصلا به این حرفا. فقط میام موقع کدنویسی نگاه میکنم کدوم تابع کدوم روش راه دسته کدنویسی منو سریعتر و راحتتر میکنه کدها کم حجم تر و خواناتر میشن. پس میام تمام فایل رو یجا با file_get_contents در یک دستور میخونم محتواش رو میریزم توی یک متغییر و بعد توی برنامه دیگه راحت باهاش کار میکنم. چه مرضیه بیام تیکه تیکه فایل رو بخونم و حلقه و تشکیلات و کد و منطق اضافه برای این کار بنویسم که چی بشه مثلا یخورده رم کمتر مصرف بشه! من حتی فایل چند مگابایتی هم باشه ترسی ندارم از این کار و مشکلی نمیدونم. بعدم گیریم که جایی این مشکل ساز شد، خب اونوقت تشخیص و حلش واقعا اونقدر سخته یعنی؟ منکه فکر نمیکنم! خب میای اون بخش کد رو عوض میکنی تغییر میدی. درسته البته بعضی وقتا شاید زیاد هم راحت نباشه بالاخره تغییر هست و تغییر ممکنه سایدافکت هایی ایجاد کنه مسائل غیرقابل پیشبینی داره یوقت میبینی به چند جای دیگر کد هم ربط پیدا میکنه و دردسرهایی حتی باگهای جدیدی بوجود بیاره، و بقول شما میگی مشکلات پشتیبانی و اینا، ولی بهرحال این باز ارزیابی و ترجیح خود شخص هست بنا به شرایط و اهداف و اولویت های خودش که کدوم مسیر رو انتخاب کنه دردسر الان رو به دردسرهای احتمالی آینده ترجیح بده یا بعکس، چقدر احتمال پیش اومدن مشکل بده، و این مسئله از فرد به فرد شرایط به شرایط میتونه تفاوت کنه یک چیز کلی و مطلقی نیست. همونطور که برنامه نویسان وردپرس اگر بهینه سازی بقدری که شما کردی نکردن شما شاید فکر کنی لازمه باید میکردن،ولی شما جای اونا نبودی شاید اونا اولویت ها و معیارهایی داشتن که با توجه به شرایط و برنامه های اونا مهمتر بوده براشون یا حداقل خودشون اونطور فکر میکردن، نمیشه براحتی تا برنامه و کدی دیدید که بهینه سازی زیادی نشده فکر کنید طرف اشتباه کرده ناشی بوده بی اطلاع بوده اون بهینه سازی که شما به ذهنت رسیده به ذهن اون نرسیده! اتفاقا بعکس ممکنه طرفها کاملا هم حرفه ای و آگاه بودن نسبت به این امور. همونطور که برنامه هایی که من نوشتم شاید آنچنان هنر بهینه سازی درشون دیده نمیشه، حتی بعضی جاها اگر از دید بهینه سازی نگاه کنی هیچی نداره و کاملا مستقیم و از کوتاهترین روش ممکن نوشته شده، ولی آیا حتما سواد من کم بوده این موارد رو نمیدونستم و آیا لزوما اشتباه کردم؟ اصلا خیلی کارهایی که من میتونم بکنم برنامه هایی که میتونم بنویسم کمتر کسی از عهدش برمیاد، و این بخاطر این نیست که من استاد مسلم بهینه سازی هستم و همه چیز رو هنرمندانه بهینه سازی میکنم! بهینه سازی امروزه فقط یکی از موارد در کنار موارد دیگری هست سواد و مهارتی که برای نوشتن برنامه های مفید نیازه، و تقریبا هیچ برنامه ای نیست که در تمام ابعاد و پارامترها حداکثری و 100% باشه یا حتی نزدیک این درصد، چون معمولا در عمل نمیشه صرف نمیکنه چنین چیزی و بجاش یک تعادل بهینه و tradeoff ها هستن که وجود دارن. مثلا من خودم به امنیت خیلی علاقه دارم و مهم میدونم، ولی دیگران اکثرا اینقدر اهمیت نمیدن سوادش رو هم ندارن. من براحتی میام از الگوریتم های سنگین رمزنگاری استفاده میکنم، گاهی چند جدول دیتابیس بخاطر یک جزییات امنیتی که فکر میکنم باید رعایت بشه اضافه میکنم چندین کوئری اضافه میکنم، دوتا دستور و تابع که در مقابل اینا هیچی نیست، و از اینکه برنامه ای نوشتم که اصولی و برتر از برنامه های دیگر هست در این زمینه لذت میبرم! بله شاید یوقت یجایی که برنامه های دیگه خوب کار میکنن برنامهء من با مشکل پرفورمنس مواجه بشه، اما فعلا مجبور نیستم نگران این موارد باشم و برنامهء من هم عوضش از نظر امنیت و بعضی جزییات در منطق و امکاناتش برتری داره بر اونا، کسی چه میدونه شاید اونا یجا هک بشن به مشکلی بخورن که باعث کلی دردسر و از بین رفتن اعتبارشون بشه! بهرحال هم هدف من اولویت من امنیت بوده اینو ترجیح دادم. فقط هم مسائل فنی نیست. این هست که کلا وقت و انرژی آدم، بخصوص آدمهای با استعداد و کسانی که هدفهای بزرگ و دور و دشوار دارن، براشون خیلی ارزشمنده مثل طلاست! من بجای اینکه وقت و انرژی خودم رو صرف این جزییات کنم که چیز جدیدی بهم یاد نمیدن، رفتم چیزهای پیشرفته ای خوندم یاد گرفتم که هرکسی بلد نیست، رفتم حیطه های دیگه مثل دسکتاپ و چندین زبان برنامه نویسی دیگه، حتی اخیرا اندروید و موبایل، یاد گرفتم، و بخاطر همینه الان میتونم کارهایی بکنم برنامه هایی بنویسم که خیلی ها نمیتونن؛ به هردوی لینوکس و ویندوز تسلط دارم و میتونم روی هردوش برنامه نویسی کنم (از اسمبلی و سی بگیر تا پایتون و سی++ و غیره). بنظر منکه این خیلی مهمتر و ارزشمندتره تا اینکه بشینم برنامه هایی رو که نوشتم بهینه کنم! کسی که ظرف یک سال و نیم 3400 مقالهء ویکیپدیا میخونه، این شخص معلومه با افراد عادی فرق میکنه و ده دقیقه وقت هم براش خیلی مهمه میخواد بیشترین استفاده مفید ممکن رو ازش بکنه، استفاده ای که فقط کوتاه مدت رو مد نظر نداره، بلکه اهداف بزرگ و دشوار و دوردست داره و برای ده سال دیگه هم فکر میکنه جای رشد داره هنوز. و منی که میتونم برنامه های بیشتری بنویسم، خب برنامه های بیشتری مینویسم، چون برنامه هایی که من میتونم بنویسم چیزهای جالب و جدید هستن و چیزهایی که افراد خیلی کمتری هستن انجام بدن، ولی بهینه سازی رو بعدها هرکس خواست میتونه حتی روی برنامه ها و کدهای دیگران هم کم و بیش انجام بده. اونکه یک کار جدید رو از صفر بکنی پایه گذاری کنی معمای حل نشده رو خودت به تنهایی حل کنی هست که سخت تر و مفیدتره و از هرکسی برنمیاد. البته این شرایط خاص من هم بوده و من هدف و شغلم مثل اکثریت شما برنامه نویسی تجاری و پول درآوردن از این راه نبوده! مگر هرکس برنامه نویسی بلده و برنامه های مفیدی درست میکنه و هرکس توی این فرومها میاد بحث میکنه لزوما باید شغل و درآمدش از راه برنامه نویسی باشه؟ خارجیها بسیاری از کارهای جالب و بزرگی که میکنن کار تحقیقاتی استادان دانشگاه و دانشجوهاشون و حتی افراد علاقمند دیگه بوده و هست.
14-07-1394، 02:59 ب.ظ
شما اکثر پروژه هایی که انجام دادین (تقریباً تمامشون) تا جایی که اطلاع دارم برای مصارف شخصی و استفاده توی مقیاسهای کوچک و تک کاربره بوده. وقتی توی پروژه مقیاس بزرگ کار کنید، اهمیت این وسواس در مصرف حافظه و پردازنده رو درک میکنید.
|
|
|
![[عکس: packages.gif]](http://forum.ncis.ir/images/ads/packages.gif)
کاربران در حال بازدید این موضوع: 1 مهمان