مرضی بنام وسواس بهینه سازی!

[eshpilen]

این یه مرض هست که از عقب ماندگی بشر از پیشرفت فناوری خودش حاصل شده!
البته این بعلت عدم درک صحیح فناوریها و معیار استفادهء بجای اونها هم هست.

بسیاری برنامه نویسان، وقت و انرژی زیادی رو روی تلاش برای بهینه سازیهایی صرف میکنن که در عمل نه تاثیر مفیدی برای خودشون داره و نه برای بشریت. حداقلش میشه گفت که میتونستن از اون وقت و انرژی با بازدهی خیلی بیشتری در راههای مفیدتری استفاده کنن.

البته دونستن تمام یا اکثر روشهای بهینه سازی مهم، برای یک برنامه نویس حرفه ای ضروری بنظر میرسه. هرچند با توجه به حیطه و سطح زبان و فریمورک و ابزارهای برنامه نویسی این ضرورت و حیطهء دانسته های مورد نیاز میتونه مقداری تفاوت داشته باشه. مثلا یک برنامه نویس سیستمی مسلما خیلی بیشتر با مبحث بهینه سازی بصورت اساسی سروکار داره.
یک برنامه نویس C خیلی بیشتر با بهینه سازی سروکار داره تا یک برنامه نویس #C. چون در C# شما هرچی هم بهینه سازی جزیی یا سطح پایین بکنید، ماهیت و خودکار بودن و ساختار متفاوت سی شارپ باعث میشه بهینه سازیهای شما عملا بی تاثیر یا با تاثیرات خیلی ناچیز باشن. حتی گاهی پیش میاد که بهینه سازیهای ظاهری خاصی از دید برنامه نویس، در عمل منجر به عدم بهینگی میشن و نتایج معکوس میدن! بخصوص که برنامه نویس معمولا با تفکر بهینه سازیهایی که در ساختار یک زبان و سطح و حیطهء برنامه نویسی سازگاری ندارن، از اصول و هدف و فرضیات آماری طراحان اون زبان خارج میشه.

دونستن و تونستن، دلیل بکار بردن در هرجا یا بیشتر جاها نیست.
ممکنه ما چیزی رو بدونیم و بتونیم، اما هیچوقت ازش استفاده نکنیم یا خیلی کم ازش استفاده کنیم.

این تاپیک رو ایجاد کردم چون بنده بارها در جاهای مختلف با این مرض یا حداقل استدلالهای نادرستی که براش میشه برخورد کردم. هرچند ظاهرا برنامه نویسان زیادی اینکار رو عملا انجام میدن و گرفتار این وسواس هستن.

خوبه بدونید بسیاری برنامه نویسان متبحر، با تجربه و مشهور درمورد این مرض مستقیم و غیرمستقیم صحبت کردن یا نظراتی که درمورد بهینه سازی دادن با استدلالهای بهینه سازان وسواسی در تناقض هست.

جایی که بنده بهشون گفتم اینطور بهینه سازیهای جزیی هیچ ارزش و تاثیر عملی نداره که برنامه نویس وقت و انرژی و خوانایی و سادگی و کم حجم بودن کدش رو فداش بکنه، بهم گفتن که همین جزییات در کل و در تعداد و بار زیاد مهم و موثر میشه و بقول معروف قطره قطره جمع گردد وانگهی دریا شود :لبخند:

البته این استدلال خیلی خام و محدود هست و ابعاد دیگه و تعادلهای لازم رو بکلی نادیده گرفته.
یک دید محدود و سطحی که فقط پارامترهای محدودی رو در دنیای واقعی درنظر گرفته (یا به پارامترهای خاصی بی دلیل، اولویت خیلی بالا و کلی ای داده) و خیلی هم غیرواقعگرا هست.

اگر بهینه سازی به هر قیمتی لازم بود، ما اینهمه لایه در همه جا نداشتیم (همهء این لایه ها کلی منابع اضافه مصرف میکنن که خیلی بیشتر از منابع صرفه جویی شده با اکثر بهینه سازیهای جزیی هست). در سیستم عامل کلی لایه داریم، در نرم افزار کلی لایه داریم، در زبانهای برنامه نویسی لایه داریم، زبانهای سطح بالا داریم، امکانات سطح بالا داریم، سیستمهای خودکار داریم، حتی code generation خودکار داریم و غیره و غیره.

پس اینطور نیست که ما بخوایم به کوچکترین بهینه سازی ای گیر بدیم و بگیم باید رعایتش کنیم. خیلی موارد هست که ارزش نداره و خیلی موارد هست که عملا هیچوقت باهاش برخورد نمیشه. اینهمه امکانات برای افزایش بهره وری از وقت و انرژی برنامه نویس بوجود آمدن و کلی منابع فدای اونها شده، اونوقت ما باید چقدر وقت و انرژی روی دور زدن این هدف صرف کنیم؟!
اگر ما بخوایم بصورت وسواسی بهینه سازی کنیم، باید از زبان اسمبلی یا حداقل سی در بیشتر کاربردها استفاده کنیم و نه از فریمورک ها و نه از محیطهای ویژوال استفاده کنیم!!

درسته که استفاده از بعضی روشها (یا عدم استفاده از بعضی روشها!) در عمل خیلی راحتتر از کدنوشتن در سی یا عدم استفاده از فریمورکها هست، اما افزایش سرعت و صرفه جویی در منابع هم با استفاده از اون روشها، به همین نسبت درحد کمتری هست.

استدلال استفاده از این ابزارهای سطح بالا، همون استدلالی هست که چرا بهینه سازی های جزیی در برنامه نویسی تا وقتی لازم نشدن و اثرشون واقعی نشده و آزمایششون نکردیم، نباید انجام بشن (مگر اینکه انجامش خیلی راحت باشه و هزینهء قابل توجهی نداشته باشه).

یک جا مثلا گفته بودن برای آدرس دهی از آدرس دهی مطلق استفاده کنید چون سریعتر هست.
جای دیگه گفته بودن از ویژگی درج متغییرهای PHP در رشته ها بطور کلی استفاده نکنید.
و مسائلی از این دست.
البته این توصیه ها از نظر راحتی کاربرد و میزان تفاوت سرعت فرق میکنن و بعضیاشون بیشتر معقول هستن و بیشتر در عمل امکان تاثیر یا نیاز عملی دارن، ولی فکر نمیکنم هیچکدام اونقدری عمومی باشن که توصیهء کلی بکنیم که از یک امکان زبان یا کتابخانه و فریمورک و ابزار استفاده نشه.

خوبه که تفکر بهینه سازی منابع رو فقط بهینه سازی فنی و سرعت و مصرف حافظه و دیسک تلقی نکنیم، بلکه بهینه سازی منابع انسانی و وقت و انرژی برنامه نویس رو هم بحساب بیاریم. یک برنامه نویس خوب که بتونه بجای یک برنامه دوتا برنامه بنویسه، عملا خیلی بیشتر به نفع خودش و بشریت کار کرده تا اینکه این وقت و انرژی رو روی بهینه سازیهای وسواسی یک برنامهء خاص صرف میکرد.

تا یک مقاله ای رو از کسی دربارهء فلان بهینه سازی خوندیم فکر نکنیم باید اون بهینه سازی رو همیشه و هرجایی یا بیشتر وقتها و بیشتر جاها بکار ببریم. شاید برای اون طرف در شرایط و نیاز و کاربرد خودش خیلی مفیدتر بوده. و شاید اصلا طرف هم اظهار نظر نادقیق و وسواسی کرده!
هوشمند بودن و برنامه های قوی و مبتکرانه نوشتن لزوما بدین معنا نیست که طرف از بیماری وسواس و نقصهای تفکر منطقی دیگه رنج نمیبره!! فکر میکنم در تاریخ ما نوابغی داشتیم که از جهات خاصی احمقانه عمل کردن و خیلی خام بودن :لبخند:

هرچند همونطور که گفتم، دونستن روشها و علتهای بهینه سازی واقعا لازم هست، چون کم پیش نمیاد که ما در جاهای مختلف به این موارد برمیخوریم. اما بیشتر این موارد از نوع ساختار الگوریتم هستن تا دستورات زبان و امکانات فناوری و غیره. هرچند گاهی با مشکل در اثر بهینه نبودن دستورات زبان و امکانات آماده یا مشکلاتی که بتونن با استفاده از تغییرات دستورات زبان و امکانات بکار رفته حل بشن، برخورد میکنیم.

بهینه سازی معمولا در جاهای خاصی که بیشترین تاثیر رو داره انجام میشه. مثلا در الگوریتم کلی، ارتباطات دیتابیس، گاهی در ساختمان داده ها، و غیره، نه در جزییات زبان و فریمورک.
و بهینه سازیهایی که هزینهء وقت و انرژی برنامه نویس و خوانایی و سادگی و حجم کد رو دارن، بصورت منطقی باید فقط موقعی که عملا برنامه با کارایی کافی یا مطلوب کار نمیکنه بررسی و انجام بشن.

بنظر شما معقول هست که بهینه سازی ای بکنیم که باعث میشه یک صفحهء وب یک دهم ثانیه سریعتر اجرا بشه و/یا چند کیلوبایت کمتر حافظه مصرف کنه؟ این یک دهم برای یک سایت با ترافیک معمولی و اصلا برای کل اون سرور با تمام سایتهاش که این بهینه سازی رو انجام بدن، شاید منجر به این امکان بشه که سرور بتونه بجای مثلا 1000 سایت، به 1100 سایت سرویس بده. البته من افزایش رو فکر میکنم خیلی دست بالا گرفتم تا حتی بهترین حالات رو درنظر گرفتم باشم. ولی همین 100 سایت اضافه هم، دلیل نمیشه 1000 تا یا بیشتر برنامه نویس بیان و چنین بهینه سازیهایی رو پیاده کنن. هرکدوم اگر یک ساعت بیشتر وقت و انرژی صرف کنن، معادل هزار نفر ساعت میشه. تازه هزینه ها فقط هزینهء نفر ساعت و دستمزد نیست و فقط در زمان حال و برای برنامه نویسان فعلی نیستن. برنامه با بهینه سازی اکثرا تغییرات دیگری میکنه، مثلا پیچیده تر میشه، گاهی حجیم تر میشه، و غیره. اینا باعث افزایش احتمال باگ، سخت شدن نگهداری و گسترش و غیره میشن.
اگر یک سرور سایت پرترافیکی داره که جواب نمیده، باید سرور یا سخت افزار آپگرید بشه، یا برنامه تغییرات اساسی در الگوریتم بکنه، بهینه سازیهای مهم مثل سیستم کش و دیتابیس و غیره صورت بگیرن، نه اینکه بیایم بجای دستور print از دستور echo استفاده کنیم چون دستور print دو برابر کندتر اجرا میشه (هرچند در اینمورد خاص اکثر برنامه نویسها از دستور echo استفاده میکنن که عملا هزینهء خاصی هم نداره). آیا این دوبرابر شدن به معنای دو برابر شدن سرعت برنامهء ما خواهد بود؟ مثلا اگر هر صفحهء ما در نیم ثانیه اجرا میشه، با اینکار در 25 صدم ثانیه اجرا خواهد شد؟
نه درواقع ممکنه افزایش سرعت فقط یک هزارم ثانیه باشه که باعث افزایش 2 هزارم در سرعت صفحات ما خواهد شد. یعنی حداکثر بجای 1000 کاربر به 1002 کاربر میتونیم سرویس بدیم!
تازه اینا همش تئوری هست. در عمل محدودیت های اساسی چیزهای دیگری هستن. مثل پنهای باند سرور، مصرف حافظه، پاسخگو نبودن ترافیک دیتابیس و دیسک و غیره، و با این کارها مشکلی حل نمیشه. و همیشه سیستم باید یک Margin منابع داشته باشه.

راستی این تاپیک مرتبط رو هم ببینید: http://barnamenevis.org/forum/showthread.php?t=228178

[PC2st]

اگر بهینه سازی به هر قیمتی لازم بود، ما اینهمه لایه در همه جا نداشتیم (همهء این لایه ها کلی منابع اضافه مصرف میکنن که خیلی بیشتر از منابع صرفه جویی شده با اکثر بهینه سازیهای جزیی هست). در سیستم عامل کلی لایه داریم، در نرم افزار کلی لایه داریم، در زبانهای برنامه نویسی لایه داریم، زبانهای سطح بالا داریم، امکانات سطح بالا داریم، سیستمهای خودکار داریم، حتی code generation خودکار داریم و غیره و غیره.
خوب در واقع بهینه‌سازی اینها را هم شامل می‌شه :چشمک: بهینه‌سازی می‌تواند هم در مورد performance باشد هم در مورد design... این مواردی که شما گفتید در رابطه با design بود.


خوبه که تفکر بهینه سازی منابع رو فقط بهینه سازی فنی و سرعت و مصرف حافظه و دیسک تلقی نکنیم، بلکه بهینه سازی منابع انسانی و وقت و انرژی برنامه نویس رو هم بحساب بیاریم. یک برنامه نویس خوب که بتونه بجای یک برنامه دوتا برنامه بنویسه، عملا خیلی بیشتر به نفع خودش و بشریت کار کرده تا اینکه این وقت و انرژی رو روی بهینه سازیهای وسواسی یک برنامهء خاص صرف میکرد.
این مورد، دقیقاً به عمر برنامه بستگی داره، اگر قرار هست برنامه بیش از ۳۰ سال کار کنه، چرا نباید بهینه سازی صورت بگیره؟ در آینده مطمئناً همین بهینه‌سازی‌ها بسیار کمک و کارها را راحت خواهند کرد. درسته... اگر قراره برنامه تا ۱ الی ۵ سال کار کنه، اصلا چه لزومی به بهینه‌سازی هست؟ اگر منظور شما برنامه‌های با عمر پائین و کاربردهای خاص و مهم نیست، موافقم.


بنظر شما معقول هست که بهینه سازی ای بکنیم که باعث میشه یک صفحهء وب یک دهم ثانیه سریعتر اجرا بشه و/یا چند کیلوبایت کمتر حافظه مصرف کنه؟ این یک دهم برای یک سایت با ترافیک معمولی و اصلا برای کل اون سرور با تمام سایتهاش که این بهینه سازی رو انجام بدن، شاید منجر به این امکان بشه که سرور بتونه بجای مثلا 1000 سایت، به 1100 سایت سرویس بده. البته من افزایش رو فکر میکنم خیلی دست بالا گرفتم تا حتی بهترین حالات رو درنظر گرفتم باشم. ولی همین 100 سایت اضافه هم، دلیل نمیشه 1000 تا یا بیشتر برنامه نویس بیان و چنین بهینه سازیهایی رو پیاده کنن. هرکدوم اگر یک ساعت بیشتر وقت و انرژی صرف کنن، معادل هزار نفر ساعت میشه. تازه هزینه ها فقط هزینهء نفر ساعت و دستمزد نیست و فقط در زمان حال و برای برنامه نویسان فعلی نیستن. برنامه با بهینه سازی اکثرا تغییرات دیگری میکنه، مثلا پیچیده تر میشه، گاهی حجیم تر میشه، و غیره. اینا باعث افزایش احتمال باگ، سخت شدن نگهداری و گسترش و غیره میشن.
البته این تفاوت ۱۰۰ تا هم عدد کمی نیست!

ولی در کل فکر می‌کنم منظور شما کلی است و منظور شما این است که بعضی از بهینه‌سازی‌ها واقعاً ارزشش را ندارد که وقت صرف آنها کنیم چون در نهایت؛ بازده و خروجی کار آنچنان تفاوتی نمی‌کند (قابل صرف نظر). بطوریکه اگر مجموع آن بهینه‌سازی‌ها را هم در موارد مختلف در نظر بگیریم، باز هم تفاوت محسوس نباشد... در این حالت به نظر من درست می‌گوئید.

[eshpilen]

این مورد، دقیقاً به عمر برنامه بستگی داره، اگر قرار هست برنامه بیش از ۳۰ سال کار کنه، چرا نباید بهینه سازی صورت بگیره؟ در آینده مطمئناً همین بهینه‌سازی‌ها بسیار کمک و کارها را راحت خواهند کرد. درسته... اگر قراره برنامه تا ۱ الی ۵ سال کار کنه، اصلا چه لزومی به بهینه‌سازی هست؟ اگر منظور شما برنامه‌های با عمر پائین و کاربردهای خاص و مهم نیست، موافقم.آخه حتی بهینه سازی درمورد اینطور برنامه ها هم حد و حدودی داره.
مثلا آیا تمام کرنل سیستم عامل با اسمبلی نوشته میشه؟ فکر نمیکنم.
درصورتیکه اگر بهینه سازی در هر حدی فقط با شرط اینکه برنامه بخواد سالها کار بکنه، لازم بود، خب چرا نمیان اگر تمام سیستم عامل رو با اسمبلی بنویسن حداقل کرنلش رو با اسمبلی بنویسن. بهرحال اسمبلی در تقریبا تمام موارد سرعت اجرا رو بالا میبره و این بالا رفتن در بیشتر موارد چشمگیر هم هست. در حالتهایی هست که اسمبلی میتونه حتی تا ۳۰۰ برابر سرعت اجرا رو بالا ببره. اما بهرصورت حتی برای برنامه هایی که بخوان ۵۰ سال هم استفاده بشن و اینقدر نقش حیاتی و پایه داشته باشن، هر مقدار بهینه سازی ای صرف نمیکنه.
شاید این بخاطر این باشه که Productivity برنامه نویسان ارزش بیشتری داره.
ممکنه با بالا بردن سرعت یک برنامه که میخواد ۲۰ سال کار کنه مقداری منفعت به شخص و شرکت خاصی یا حتی بشریت برسه در طول عمر اون محصول، اما وقتی همون برنامه نویسها بتونن روی برنامه های بیشتری در زمینه های بیشتری کار کنن یا الگوریتم و سیستمهای جدیدی ابداع کنن، برای همه خیلی مفیدتر خواهد بود.


ولی در کل فکر می‌کنم منظور شما کلی است و منظور شما این است که بعضی از بهینه‌سازی‌ها واقعاً ارزشش را ندارد که وقت صرف آنها کنیم چون در نهایت؛ بازده و خروجی کار آنچنان تفاوتی نمی‌کند (قابل صرف نظر). بطوریکه اگر مجموع آن بهینه‌سازی‌ها را هم در موارد مختلف در نظر بگیریم، باز هم تفاوت محسوس نباشد... در این حالت به نظر من درست می‌گوئید.بله درواقع خیلی بهینه سازیهایی که خیلی برنامه نویسها انجام میدن یا حداقل اینطور ادعا میکنن و دیگران رو تشویق بهش میکنن از این مقوله هست.
مثلا روی جزییات اجزای زبان مانور میدن و میگن از فلان دستور، تابع، یا ساختار استفاده نکنید (بطور کلی) و از فلان یکی استفاده کنید چون سرعتش چند برابره. درحالیکه عملا مثلا یکی در یک میکروثانیه اجرا میشه و دیگری در ۳ میکروثانیه. خب این اختلاف که باعث نمیشه سرعت برنامهء ما ۳ برابر بشه! بلکه فقط ممکنه در کل چند صدم ثانیه سرعتش بیشتر بشه.
و اصلا گاهی هست که حتی سرعت برنامهء ما چند برابر هم بشه چندان مهم نیست، چون بهرحال سرعت برنامهء ما در حالت غیربهینه هم مناسبه. مثلا برناممون بطور معمول در یک دهم ثانیه اجرا میشه. البته بسته به نوع برنامه و تعداد نسخه های در حال اجرا و پارامترهای دیگری هم هست.

[eshpilen]

ببینید مثلا یه چیزی که توی فرومهای PHP همینطوری مثل نقل و نبات میگن اینه که از Variable Interpolation استفاده نکنید و بجاش از Concatenation استفاده کنید.
اما این حرف یعنی محروم کردن خودمون از یکی از امکانات مفید و سطح بالای زبان.

حالا تفاوت راحتی کدنویسی و خوانایی این دو قطعه کد رو با هرکدوم از این دو روش به ترتیب مشاهده کنید:


echo "Welcome $name $family!"

echo 'Welcome '.$name.' '.$family.'!'

اولی Interpolation هست و دومی Concatenation.

البته در تمام موارد اینقدر اختلاف ظاهری نیست و من این مثال رو مخصوصا انتخاب کردم که تفاوت ظاهری دو روش کاملا مشخص باشه.
تازه حتی تفاوت سرعت این دو روش هم به طول رشته و تعداد متغییرها و پیچیدگی اون برمیگرده و تفاوت میکنه. مثلا در مورد رشته های ساده و کوتاه، روش Concatenation اونطوری که من تست کردم فقط حدود ۵۰٪ برابر سریعتر بود. اما درمورد رشته های دیگه سرعتش تا ۳ برابر (یا کمی بیشتر) سرعت Interpolation میرسید.
بهرحال ما هرکدوم از ساختارها و دستورات و توابع زبان و کتابخانه ای رو اگر تست کنیم، مسلما با هم اختلاف سرعت دارن و اختلاف سرعتهای سه چهار برابر هم چیز نامعمولی نیست بنظرم. هرچند همونطور که دیدید به شرایط هم برمیگرده و این میزان تفاوت متغییر هست. آیا ما باید بیایم به این خاطر از یکسری امکانات و ساختارها استفاده نکنیم؟ یا تفکر درست این هست که موقعی که برنامه نیاز عملی به بهینه سازی پیدا میکنه و متوجه میشیم با این روشها میتونیم نتیجهء مطلوب بدست بیاریم باید اینکار رو بکنیم؟

[nima898]

من هم موافقم مرض بدیه من هم این مشگل داشتم ولی بعد شناختمش و الان دیگه وسواسی ندارم

[East.Tiva]

به نظر من اگر آدم کاری می تونه انجام بده، باید انجامش بده !
اوایلش شاید خیلی سخت و زمانبر و فکرسوز! باشه برای آدم، ولی بعد از چندبار تبدیل میشه به روتین برنامه نویسیتون و اونوقت بدون هیچ فشار خاصی، برنامه هایی می نویسید که هم کدزیبا دارند و هم کارایی بالا و بهینه!
پس بنابراین تنبلی نکنید و سعی کنید این مهارت رو هم به کارتون اضافه کنید.

[eshpilen]

اشتباه نکن. ما نمیگیم این مهارت رو نداشته باشیم و جاهایی که لازمه استفاده نکنیم.
ولی بهینه سازی بهرصورت غیر از وقتی که میبره اثرهای جانبی دیگه هم داره خیلی وقتا. مثلا خوانایی کد رو کم میکنه، انعطافش رو کم میکنه و غیره. اینا در عمل مشخص میشن. بنابراین بهینه سازی رو باید جایی که لازمه انجام داد. ضمنا منظور ما بیشتر بهینه سازیهای موردی و جزیی هست که اثر اونها معمولا ناچیزه، و ضرورتی هم ندارن.

[East.Tiva]

من خودم توی کارم، موردهایی بوده که برای یک ثانیه کمتر 3-2 روز وقت گذاشتم، هیچ وقت مشکلی هم برام پیش نیومده، ضمن اینکه الان دیگه همون کار 3-2 روز که هیچ! انجام دادنش 3-2 دقیقه وقت میبره ، و از اون روز به بعد توی همه پروژه هام دارم استفاده می کنم.

منظورم اینه که اگر یکبار هرچقدر هم کم، ولی انجامش بدید، از دفعه بعد کلی به نفعتون میشه و همین یک ثانیه یک ثانیه ها ، یه جایی کلی شما را جلو می ندازه !!

واقعا اثرش رو دیدم که دارم میگم.

[eshpilen]

قضیه گسترده تر و پیچیده تر از این حرفهاست.
بهینه سازی میتونه به شکلهایی خیلی فراتر از اینها باشه.
مثلا ممکنه جایی چند هزار خط کد نوشته بشه فقط برای بهینه سازی!
بهینه سازی که فقط استفاده از i++ بجای i=i+1 نیست!!
ممکنه یک سیستم پیچیده پیاده بشه، فقط بخاطر بهینه سازی یک بخش از یک برنامهء بزرگتر.
حالا شما در کارهای محدود و کوچک خودتون برخوردی نداشتید اینا رو درنظر نمیگیرید.
فرضا در یک سیستم DBMS که توسعه میدن ممکنه هزاران خط کد و کلی الگوریتم و تشکیلات فقط صرف بهینه سازی برای بالا بردن سرعت یک بخش از عملیات اون بشه. ممکنه برنامه حتی با اینطور بهینه سازیهای پیچیده فضای دیسک و RAM بیشتری هم مصرف بکنه، اما عملا سرعتش با اون سیستم و الگوریتم ها، بالاتر بره (بقول طرف، بستگی داره ما برای چی بهینه سازی بکنیم؛ ولی در بیشتر کاربردها هدف سرعته).
مسلما چنین کاری دیگه بحث چند دقیقه و مقدار جزیی تغییرات در کد و ساختار برنامه نیست.
بنابراین اگر اثر این بهینه سازی جزیی باشه، صرف نداره و معقول نیست پیاده بشه. مگر یه زمانی که منطق و عملیات برنامه از همه لحاظ کامل شده و برای مدت زیادی میخواد پایدار بمونه. در اون شرایط ممکنه به علت بازدهی بیشتر برنامه در طولانی مدت، مقداری بهینه سازیهای جزیی که در عمل مفید تشخیص داده میشن هم روش انجام بشه. و البته چون اون موقع منطق و عملیات و تست و باگیابی برنامه تموم شده، اینکار خیلی راحتتر و سریعتر صورت میگیره تا اینکه از اول و هنگام توسعهء برنامه میخواستن اون سیستم بهینه سازی رو هم همزمان پیاده سازی بکنن (که برنامه رو پیچیده و حجیم و پیگیری الگوریتم ها رو خیلی دشوار میکنه).
قاعدهء معقول بهینه سازی همونه که جایی که لازمه بهینه سازی کنیم. و البته کسی که دانش و مهارت بهینه سازی رو داشته باشه، کم نمیاره! چون هروقت برنامش کم آورد و نیاز به بهینه سازی داشت میتونه براحتی اینکار رو انجام بده.
به اون مثالی که در این تاپیک (http://barnamenevis.org/forum/showthread.php?t=228178) آمده اگر دقت کنید همین رو میگه که یک پروژهء تحت وب که پیاده سازی منطق اصلی اون 3 ماه طول کشیده رو در عرض 3 روز بهینه کرده و اگر حساب کنید سرعتش رو 48 برابر بیشتر کرده!
یعنی بهینه سازی به خودی خودش بعد از انجام منطق اصلی کار و وقتی برنامه واقعا نیاز به بهینه سازی داشت میتونه در زمان کوتاهی انجام بشه و کاملا نتیجه بخش هم باشه.
برنامه های پیچیده و بزرگ رو ممکنه حتی با زبانهای سطح بالای خاصی مثل پایتون Prototype بکنن تا پیاده سازی و آزمایش الگوریتم اصلی و منطق برنامه رو بتونن راحتتر و سریعتر انجام بدن؛ درحالیکه سرعت پایتون کمتر هست و بهینه سازی های جزیی توش انجام نمیشه؛ بعد تازه میان برنامه رو به سی++ تبدیل میکنن و احتمالا بهینه سازیهایی رو که میخوان روش انجام میدن.
پس همونطور که در اون مقاله اشاره شده، بهینه سازی رو در برنامه های بزرگ همیشه دست آخر انجام میدن و موقعی که واقعا لازم و مفید هم تشخیص داده بشه. وگرنه اگر میخواستن از اول برنامه رو بهینه بنویسن و پیاده سازی در یک زبان سطح پایینتر و انجام تمام بهینه سازیها اینقدر راحت و سریع بود دیگه Prototype کردن برنامه در پایتون برای چی بود!؟
شما دوتا برنامهء کوچیک و محدود و اپلیکیشن های ساده رو نگاه نکنید، در کاربردهای بزرگ و الگوریتم های علمی پیچیده و نیازهای خاص، اونقدر الگوریتم و پیاده سازی منطق اصلی خود برنامه ممکنه پیچیده و حجیم باشه که اگر بخوان کد رو از اول با بهینه سازی کامل بنویسن کار خیلی مشکل تر و طولانی تر میشه، چه برسه به اینکه بخوان بهینه سازیهای جزیی رو که لازم نیستن هم انجام بدن.
شما یه عملیات رو سرراست و با فرمول کلی بخواید پیاده سازی کنید راحتتره یا اینکه هوشمندش کنید و با توجه به شرایط الگوریتم بهینه شده ای داشته باشه؟ بهینه سازیهای پیشرفته اکثرا کد بیشتر و/یا ناخواناتر و الگوریتم پیچیده تری دارن و این تعداد باگها و نیاز به تست برنامه در شرایط مختلف رو هم به شدت بالا میبره.
حالا یه برنامهء بزرگ و پیچیده اگر از اول بخواد همه نوع بهینه سازی داشته باشه، احتمالا دیگه توی کلاف سردرگم باگ و انبوه کدها گم میشن برنامه نویسها! دست آخر هم برنامه ای که بیرون میاد به احتمال زیاد هنوز باگهایی داره که کشف نشدن.

[eshpilen]

من خودم توی کارم، موردهایی بوده که برای یک ثانیه کمتر 3-2 روز وقت گذاشتم، هیچ وقت مشکلی هم برام پیش نیومده، ضمن اینکه الان دیگه همون کار 3-2 روز که هیچ! انجام دادنش 3-2 دقیقه وقت میبره ، و از اون روز به بعد توی همه پروژه هام دارم استفاده می کنم.
وقت و انرژی 3 روز رو گذاشتن برای یک ثانیه بالا بردن زمان، معقول نیست مگر اینکه واقعا نیاز بوده باشه (کاربرد شما چی بوده دقیقا؟) یا بخاطر تمرین انجام شده باشه. تمرین رو هم آدم یکبار و چند بار یا هر از چند گاهی انجام میده، نه هزار بار یا هر روز و هر ساعت!!
وگرنه همون وقت و انرژی رو آدم میتونه صرف کارهای مفیدتر هم بکنه و مثلا دانش و مهارت برنامه نویسی خودش رو توی چیزهای مفیدتر و زمینه هایی که کار نکرده گسترش بده.


منظورم اینه که اگر یکبار هرچقدر هم کم، ولی انجامش بدید، از دفعه بعد کلی به نفعتون میشه و همین یک ثانیه یک ثانیه ها ، یه جایی کلی شما را جلو می ندازه !!

واقعا اثرش رو دیدم که دارم میگم.
مثلا کجا؟
اگر شما عملا دیدید که مثال عمیلش رو بزنید.

ضمنا بازم میگم که ما میگیم برنامه نویس باید دانش و مهارت انواع بهینه سازی رو داشته باشه، ولی حرف اینه که نیازی نیست همه جا همه طور بهینه سازی ای رو که بلده انجام بده. اینکار هم وقت و انرژی رو هدر میده و هم کد رو ناخوانا و پیچیده و حجیم میکنه و همه میدونن که خوانایی و کم بودن حجم کد امروزه یکی از معیارهای خیلی مهم هست چون در عمل تاثیرات مهمی داره (بخصوص درمورد برنامه های بزرگتر و پیچیده تر).

خیلی ریزه کاریها در کد هست که انجامش حتی اگر ظاهرا فکر میکنید وقت و انرژی زیادی نمیبره، اما بعضی این عوارض رو داره و جاهای دیگه بصورت غیرمستقیم هزینه تحمیل میکنه. چه بسا فلان باگ که توی برنامه درمیاد و کشف علتش و رفعش وقت و انرژی قابل توجهی میبره، در اثر ابهام و حجم و پیچیدگی بیش از حد نیاز کد ایجاد شده بوده باشه.
من فکر نمیکنم واقعا معقول باشه آدم وقت و انرژیش رو که اینقدر کمیاب و ارزشمند هست و میتونه روی کارهای مفیدتری هم صرف کنه بذاره روی بهینه سازی جزیی هر برنامه ای و اینکار رو مدام تکرار و تکرار کنه! کافیه آدم دانش لازم رو داشته باشه و یکبار هم مثلا بصورت تمرین انجام داده باشه یا حتی توی یک کار عملی که نیاز میشه بهش بربخوره و انجامش بده، دیگه پیاده سازی اون مورد توی هر کد و کاربرد و برنامه ای که منجر به مقدار ناچیزی افزایش سرعت میشه چه توجیهی داره؟

تازه اگر وقت صرف شده رو هم ناچیز بدونیم، ناخوانایی و پیچیدگی کد و الگوریتم و انرژی ای که خود برنامه نویس یا احتمالا برنامه نویسان دیگه برای مطالعه و درک و تست اون کد صرف میکنن، خودش یه امتیاز منفی بزرگ محسوب میشه. هرچیزی هرچقدر ساده تر و کوتاهتر و خواناتر باشه مسلما بهتره و در طول زمان ممکنه این مسئله برجسته تر هم بشه، یا وقتی افراد دیگه میخوان از اون کد استفاده بکنن.
یه وقت ممکنه مطالعه و نوشتن و دنبال کردن یک کد یا الگوریتمی، از نظر زمان نسبتا سریع باشه، اما نیاز به تمرکز و تحلیل ذهنی سنگینی داره که مغز آدم رو خسته میکنه. بعد شما اون نیم ساعت رو که جای دیگه بعلت این خستگی باید چرت بزنی و تمرکز نداری یا راندمان مغز میاد پایین حساب نمیکنی که!
همون انرژی و تمرکز و تحلیل رو آدم میتونه صرف کارهایی بکنه که در عمل بازدهی خیلی بالاتری دارن. من باشم میرم چیزای جدید یاد میگیرم بجای اینکه چیزهایی رو که از قبل میدونم به شکلهای مختلف و در جاهای مختلف بدون اینکه بازدهی مهمی داشته باشن پیاده بکنم.

[East.Tiva]

مورد خاصی نبوده، فقط من عقیده دارم که کارهایی که من انجام میدم باید حداکثر کیفیت ممکن رو داشته باشند و اگر جایی می تونم حتی 1% بهتر بنویسم باید اون 1% اعمال بشه. حتی موردهایی بوده که کد کامل و سالم و خوب هم بوده اما خوانایی و زیبایی کد پایین بوده، واسه اون هم وقت می ذارم و کد خوانا و خوب می نویسم.
ساده ترین و معمول ترین استفادش در زمانی هست که یک نفر دیگه بخواد بشینه پشت کد شما، یا از کدهای سطح پایین تر شما استفاده کنه. پس بهتره که اونها تا حدممکن بهینه و خوانا باشند تا در سطوح بالاتر (که معمولا کارخرابی! زیاد می شود) مشکلات کمتری باشه.

در مورد بهینه سازی های پیچیده، خب مسلما همین هست که شما میگید. اگر به پست اول خود مراجعه کنید، بحث ما بر سر بهینه سازی های پیچیده که سرعت رو 48برابر! می کنند نبوده اصلا!
بحث ما برسر بهینه سازیهای وقت گیر که اتفاقا تاثیر چندانی هم ندارند بوده که شما گفتید نباید انجام بشه، من میگم که باید انجام بشه ! (رجوع شود به پست اول)

[eshpilen]

بحث ما برسر بهینه سازیهای وقت گیر که اتفاقا تاثیر چندانی هم ندارند بوده که شما گفتید نباید انجام بشه، من میگم که باید انجام بشه ! (رجوع شود به پست اول)خب چرا؟ یک دلیل منطقی بیارید.
اگر وقت گیر باشه ولی در عمل تاثیر مهمی نداشته باشه چرا باید این وقت و انرژی رو صرفش بکنیم؟
شما در اون پستتون هم هیچ نمونه و دلیل روشن و عملی ای ارائه نکردید. فقط گفتید اینکار بنظرتون خوبه و بعدا تاثیرش رو میبینید. و شما میگید با تکرار و تجربه در جاهای دیگه این بهینه سازیها زمان خیلی کمتری میبره، اما این حرف کلی ثابت نشده. خیلی از بهینه سازیها هستن که هرجا باید به شکل خاص خودش پیاده بشن و کد رو ناخوانا و پیچیده میکنن. بهینه سازی خیلی گسترده هست و درمورد هر برنامهء خاص تقریبا بهینه سازیهای موردی و خاص و جدید هم ممکنه پیش بیان که کدها و تجربیات گذشتهء شما، مشکل وقت و انرژی لازم و ناخوانایی و پیچیدگی کد و بالا رفتن امکان باگها رو بطور کامل حل نمیکنن.
امروزه سینتاکس زبانها رو هم طوری طراحی میکنن که خوانایی و کوتاهی کد حداکثر باشه و این مسئله خیلی مهمه و یکی از اولویت های اول بخصوص در پروژه های بزرگه، اونوقت بهینه سازی که اکثرا درگیر با تغییر شکل کد و پیچیده و غیرمستقیم شدن الگوریتم و افزایش حجم کد و غیره هست موجب کم شدن خوانایی و کوتاهی کد نمیشه؟! حتی شما اگر از روشهای بهینه سازی دقیقا یکسان و کدهای گذشته استفاده کنید، بازم این با یک کد سرراست و کوتاه خیلی فرق میکنه و شما چیزهایی خارج از ساختار اصلی رو آوردید توی کد اضافه کردید که مسلما کم و بیش منجر به افزایش حجم کد، پیچیدگی دنبال کردن جریان برنامه، ناخوانایی و ابهام و بنابراین هدر رفتن وقت و انرژی و افزایش باگها میشه.



در مورد بهینه سازی های پیچیده، خب مسلما همین هست که شما میگید. اگر به پست اول خود مراجعه کنید، بحث ما بر سر بهینه سازی های پیچیده که سرعت رو 48برابر! می کنند نبوده اصلا!منظورم این بود که بهینه سازیهای ضروری بعد از تکمیل برنامه هم میتونن انجام بشن و اینکار با سرعت زیاد و تاثیر بخشی کافی هم میتونه انجام بشه. بنابراین ضرورتی نداره موقع پیاده کردن برنامه اصلی ما هر بهینه سازی ای رو که بنظرمون میاد پیاده کنیم. این کار وقت و انرژی خیلی بیشتری رو هدر میده به دلایلی که مولف هم بهش اشاره کرده. خیلی از این بهینه سازیها درعمل بیهوده بودن ولی موقعی که برنامه هنوز به جایی نرسیده بوده مشخص نمیشده. از طرف دیگه بهینه سازی چون اغلب موجب ناخوانایی و افزایش حجم و پیچیدگی کد میشه، تموم شدن برنامه رو سخت تر و طولانی تر میکنه؛ ولی اگر اول منطق و الگوریتم اصلی برنامه رو کامل کنید و بعد اگر نیاز به بهینه سازی بود، بهینه سازی کنید، سرعت کار شما بیشتر خواهد بود.


فقط من عقیده دارم که کارهایی که من انجام میدم باید حداکثر کیفیت ممکن رو داشته باشند و اگر جایی می تونم حتی 1% بهتر بنویسم باید اون 1% اعمال بشه.آخه موضوع کیفیت فقط به سرعت برنمیگرده که.
شما کیفیت رو فقط سرعت تعریف میکنید؟ اونم 1%؟
کیفیت یک برنامه شامل خیلی پارامترها میشه.
در خیلی موارد بهینه سازی در برابر پارامترهای دیگه قرار میگیره.
مثلا بهینه سازی بخاطر افزایش حجم کد و پیچیدگی و ناخوانایی اون، باعث افزایش احتمال باگ در برنامه میشه.
بنظر شما خطر کمتر وجود باگ در برنامه، جزو کیفیت نیست و در همه جا بخاطر 1% بهینه سازی در سرعت باید ریسک باگ در برنامه رو بالا برد؟ شما نگاه کنید بهترین برنامه نویسان و بزرگترین شرکتهای جهان هم نمیتونن حتی با وجود مدتها تست، برنامه ای بنویسن که همهء معیارها رو درحد 100% داشته باشه. یعنی هم سرعتش حداکثر ممکن باشه، هم باگ نداشته باشه، هم خوانا باشه و غیره. شما میتونید؟ اصلا اگر بخوان سرعت برنامه حداکثر باشه باید از زبان اسمبلی یا حداقل سی استفاده کنن. تازه استفاده از این زبانها معمولا خیلی یا چند برابر بیشتر از 1% سرعت رو بالا میبره. آیا شما از این زبانها برای تمام پروژه هاتون استفاده میکنید؟ اگر نمیکنید، پس قبول دارید که یک تعادلی باید بین پارامترهای مختلف که وقت و انرژی برنامه نویس هم جزوش هست وجود داشته باشه و صرفا با تجربه و مهارت و تکرار و استفاده از کدهای قبلی نمیشه همه یا بیشتر کارها رو اونقدری راحت کرد که دیگه بحث بهینه سازی در مواقع لازم اهمیت نداشته باشه.
شما خودتون رو هم بکشید برای بهینه سازی، بازم اغلب سرعت برنامهء شما که در سی شارپ یا جاوا نوشته شده، به کد بهینه شدهء سی نمیرسه.
این استدلال به همین صورت قابل تعمیم و معتبر در بقیهء قضیه هست.
خلاصه شما چیزی میگید که خودتون هم درش به تناقض میخورید.
میگید از 1% هم نمیگذرید؛ پس سوال پیش میاد که چرا از اسمبلی یا سی برای تمام برنامه ها استفاده نمیکنید تا بیش از 1% سرعت بالا بره؟
میگید با تجربه و مهارت و استفاده از الگوریتم ها و کدهای قبلی، سرعت و راحتی کار در دفعات بعد خیلی بیشتر میشه و دیگه مسئله ای نیست. اما اگر اینطور باشه این مسئله به زبان هم قابل تعمیم هست چون استفاده از زبان سطح پایینتر هم خودش یجور بهینه سازی هست. اما خودتون میدونید با تجربه ترین برنامه نویسان با تمام امکانات و کتابخانه های آماده هم، نمیتونن در تمام یا حتی بیشتر موارد، سرعت برابر با برنامه نوشتن در یک زبان و فریمورک سطح بالاتر رو داشته باشن و اون زبان و فریمورک سطح بالاتر به نوبهء خودش کتابخانه های سطح بالاتر هم میتونه داشته باشه.

اصلا چرا این زبانهای سطح بالاتر و فریمورک ها و لایه های انتزاع بوجود آمدن؟ تمام اینا کلی منابع سیستم رو مصرف میکنه و سرعت رو هم پایین میاره. اگر تنها معیار مهم سرعت بود، نباید از این زبانها و فناوریها استفاده میشد. چون خاصیت عمدهء این زبانها و فناوریها، بیشتر همون صرف وقت و انرژی کمتر برای برنامه نویس و خوانایی و کوتاهی کد و کم شدن باگ و غیره هست، نه بهینه شدن فنی برنامه و افزایش سرعت که تقریبا همیشه رابطهء معکوس داره!

بنابراین تعریف بهترین بودن یک برنامه این نیست که بخاطر 1% سرعت اجرای بیشتر بیایم و خودمون رو از مزایای زبانها و ساختار کدنویسی سطح بالا و خوانا محروم بکنیم. اگر میخوایم اینکار رو بکنیم پس بریم از زبان سی استفاده بکنیم که بجای یک درصد حداقل 10% بهمون افزایش سرعت میده!

[eshpilen]

اصلا مگه من مثال عملی نزدم؟
چرا با مثالهای عملی حرفی رو که میزنید ثابت نمیکنید؟
شما میگید بخاطر 1% افزایش سرعت هم که شده باید بهینه کنیم و این بهینه سازیها با تکرار و تجربه در موردهای دیگه خیلی راحتتر و سریعتر میشن. درست؟
وقتی این رو میگید یعنی حرفتون کلی هست یا حداقل در بیشتر موارد صدق میکنه.



echo "Welcome $name $family!"

echo 'Welcome '.$name.' '.$family.'!'
اولی Interpolation هست و دومی Concatenation.

این دوتا کد هردو یک کار رو میکنن، ولی در نوشتن تفاوت قابل توجهی دارن.
اولی بنحو قابل توجهی خواناتر، کوتاهتر و راحتتر برای تشخیص اشتباهات و تغییرات هست. بنظر شما غیر از اینه؟
دومی رو بخوای بنویسی هرچقدر هم مهارت داشته باشی بازم نیاز به دقت بیشتری داره و وقت و انرژی بیشتری میبره و چش و چال آدم هم درمیاد! از کدهای آمادهء خاصی هم نمیشه کپی پیست کرد. غیر از اینه؟ احتمال خطای سینتاکس یا باگ درآمدن توش زیادتر هست. همهء اینا بهم مرتبط هستن و بعضیا نتیجهء بعضیای دیگه، ولی همه رو برمی شمارم تا حواستون به تمام عوارض معمول و ممکن اینطور کدنویسی باشه.
سرعت اجرای روش دوم بیشتر هست. و در کل یک صفحهء سایت یا اپلیکیشن وب عادی نمیدونم مجموعا چقدر سرعت رو بالا میبره، ولی بهرحال اونقدری زیاد نیست که محسوس باشه.
شما حساب کنید ما هرجا بخوایم از روش دوم استفاده کنیم در کل یک برنامهء وب معمولی گاهی چند صدتا از ترکیب رشته های مختلف مثل این هست. حالا اینا درکل چقدر به چشم فشار میاره و چقدر تمرکز و قوای ذهنی میبره و چقدر وقت میبره خودتون باید بتونید بفهمید. دست آخر چی عایدمون میشه؟ مثلا 1% افزایش در سرعت. کمتر یا بیشتر، بهرحال کسر کوچکی از یک ثانیه خواهد بود. مثلا صفحهء وبسایت شما اگر قبلا در یک صدم ثانیه پردازش و به کاربر ارسال میشده، حالا یک صدم از یک صدم ثانیه زودتر، یعنی یک ده هزارم ثانیه زودتر به کاربر ارسال میشه!
بنظر شما بازم ما میباید از روش دوم استفاده کنیم؟
و اگر واقعا 1% افزایش سرعت به هر بهایی در هرجایی و شرایطی مهمه، پس چرا اصلا بجای PHP از سی استفاده نکنیم که بجای یک درصد 10% (و شاید خیلی بیشتر) افزایش سرعت داشته باشیم؟

مثال بخواید بازم میتونم براتون بزنم.
شما هم اگر ادعایی رو که میکنید با نمونه های عملی ثابت کنید خیلی ممنون میشم.
چون صحت ادعای شما اصلا کلی و بدیهی بنظر نمیاد.
آدم توی بحث علمی و تخصصی و چیزی مثل برنامه نویسی که کاملا عملی و کاربردی و قابل تست هست که نباید بیاد بگه بنظر من! مگه بحث ما سلیقه هست که کدوم رنگ رو شما خوشت میاد و کدوم رو بنده؟ بحث روی قاعده های کلی و منطقی هست. اگر شما میگی بنظر من، باید دلیل و سندش رو بیاری و درصورت لزوما با نمونه های عملی ارائه کنی.

تازه این بهینه سازی که گفتم یک چیز خیلی ساده و مختصری هست. ولی از این دست بازم هست و در یک زبان هر ساختار و تابعی رو با ساختار و تابع دیگه که میتونن بجای هم بکار برن اگر با هم مقایسه کنید، کم و بیش اختلاف سرعت دارن. ولی کسی نمیاد تمام این موارد رو تست و اعمال کنه.
روی بخشهایی که تاثیر به مراتب بیشتری میتونن داشته باشن، مثل دیتابیس، میشه خیلی بیشتر کار کرد و وقت و انرژی به مراتب بیشتری میطلبه و ضمنا بهینه سازیهایی که میشه کرد انواع و تعداد خیلی بیشتری دارن؛ اینقدر که شاید بشه ماهها روی بهینه سازیهای مختلف و تست اونها در یک برنامهء بزرگ کار انجام داد. آیا در هر برنامه ای تمام این بهینه سازیها صورت میگیرن؟ بنظر شما باید انجام بدن؟
مثلا یه سایت میخوام درست کنم. من چقدر باید وقت و انرژی روش بذارم؟ باید آخرین و تمام فناوریهای موجود در هر موردی رو استفاده کنم و جزیی ترین بهینه سازیها رو انجام بدم؟ چقدر باید روش وقت و انرژی بذارم؟ یعنی بخاطر 1% افزایش سرعت معقول هست هر مقدار زمان و انرژی ای که روش صرف کنم؟
و بنظر شما استفادهء مفیدتری از این وقت و انرژی نمیشد کرد؟
مثلا اگر میرفتم یک مبحث علمی مطالعه میکردم یا در زمینهء کامپیوتر و برنامه نویسی دامنهء دانش و مهارت خودم رو در زمینه های جدید کاربردی گسترش میدادم بهتر نبود؟ مثلا میرفتم یک زبان جدید یاد میگرفتم، روی برنامه نویسی یک مقولهء جدید مطالعه میکردم و غیره.