eshpilen
پنج شنبه 27 خرداد 1389, 02:46 صبح
بهینه سازی فرایند اجرای موثرتر برنامهء کاربردی شماست. شما میتوانید برای چیزهای زیادی بهینه سازی کنید - سرعت، مصرف حافظه، مصرف دیسک، غیره. اما ما در اینجا بر روی بهینه سازی سرعت معطوف هستیم.
-- چه وقت بهینه سازی کنیم؟
بطور کلی بهینه نکردن بهتر از بهینه سازی بیش از حد زود است. وقتیکه بهینه سازی میکنید، کد شما عموما ناواضح تر میشود، زیرا پیچیده تر میشود.
خوانندگان کد شما دردسر بیشتر برای کشف اینکه آنچه شما انجام داده اید را به چه علت انجام داده اید خواهند داشت که هزینهء نگهداری پروژهء شما را افزایش خواهد داد. حتی وقتیکه شما میدانید چطور و چرا برنامهء شما به روشی که انجام میدهد اجرا میشود، کد بهینه شده برای باگ زدایی و گسترش دشوارتر است. آن فرایند توسعه را به نحو قابل توجهی کند میکند، به هر دو علت زمانی که بهینه کردن کد میگیرد، و زمانی که تغییر کد بهینه شدهء شما میگیرد.
مکمل این مشکل این است که شما حتی از پیش نمیدانید مشکلات سرعت در برنامهء شما در کجا خواهند بود. حتی برنامه نویسان باتجربه در پیشبینی اینکه کدام بخشهای برنامه تنگه (bottleneck) هایی خواهند بود که به بهینه سازی نیاز دارند دچار دردسر هستند، بنابراین شما احتمالا در پایان با هدر دادن زمان خود برای بهینه سازی بخشهای نادرستی مواجه خواهید شد. ...
مادامیکه شما برنامه تان را توسعه میدهید، به داشتن اولویت های زیر نیاز دارید:
- همه چیز مستند شده باشد
- همه چیز همانطور که مستند شده است کار کند
- کد در یک شکل ماجولار و براحتی قابل تغییر نوشته شده باشد
مستندات اساسی هستند، بخصوص هنگام کار در گروهها. عملکرد مناسب برنامه اساسی است. شما متوجه خواهید شد که سرعت برنامهء کاربردی در هرجایی در آن لیست نیست. بهینه سازی در توسعهء اولیه به علتهای زیر لازم نیست:
- مشکلات سرعت کوچک معمولا میتوانند از طریق سخت افزار حل شوند، که اغلب از وقت یک برنامه نویس بسیار ارزانتر هستند.
- برنامهء کاربردی شما همانطور که شما آنرا مورد تجدیدنظر قرار میدهید به طرز قابل توجهی تغییر میکند، بنابراین بیشتر کوشش های شما برای بهینه سازی آن هدر میرود (بسیاری پروژه های جدید اغلب یک کد پایه دارند که همانطور که توسعه دهندگان دربارهء مسئله ای که آنها درحال تلاش برای حلش هستند بیشتر یاد میگیرند بطور کامل بازنویسی میشود. هر بهینه سازی انجام شده روی کد پایهء نخستین به کلی هدر رفته است).
- مشکلات سرعت معمولا در مکانهای معدودی در کد شما هستند - پیدا کردن آنها قبل از آنکه شما بیشتر برنامه را تمام کرده باشید دشوار است.
بنابراین، وقت بهینه کردن در انتهای توسعه است، وقتیکه شما مطمئن شده اید که کد صحیح شما عملا مشکلات کارایی (performance) دارد.
در یک پروژهء تجارت الکترونیک مبتنی بر وب که من در آن درگیر بودم، تماما بر روی صحت تمرکز کردم. این برای ناراحتی همکارانم که دربارهء این واقعیت که پردازش هر صفحه قبل از اینکه اصلا شروع به بار شدن کند دوازده ثانیه زمان میبرد (بیشتر صفحات وب در زیر یک ثانیه پردازش میشوند) خیلی سنگین بود. هرچند، من تصمیم گرفته بودم نخست آنرا به روش صحیح بسازم، و بهینه سازی را بعنوان یک اولویت آخر قرار دهم. وقتیکه کد پس از ۳ ماه نهایتا صحیح بود، پیدا کردن و برطرف کردن تنگه ها فقط سه روز طول کشید و میانگین زمان پردازش را به زیر یک چهارم ثانیه آورد. با تمرکز بر روی کد صحیح، من توانستم پروژه ای را که هم صحیح و هم کارا بود تمام کنم.
----------------------------------
م: تنگه (bottleneck) به بخشهایی از برنامه یا هر سیستمی میگویند که حاصل تمام بخشهای دیگر یا بازدهی نهایی سیستم تحت تاثیر آنست (بنوعی مجبور به گذر از آن است، و غیره) و بنابراین محدودیت اصلی کارایی برنامه در این بخش از برنامه قرار دارد که در موارد مشکل باعث افت کلی بازدهی سیستم به زیر حد مورد نیاز یا حد قابل تحمل میشود، باوجود اینکه در بخشهای دیگر برنامه/سیستم چنین محدودیتی وجود نداشته باشد یا حتی ظرفیت بالاتر از حد نیاز وجود داشته باشد.
======================
منبع:
Programming from the Ground Up
Jonathan Bartlett
Edited by
Dominick Bruno, Jr.
http://download.savannah.gnu.org/releases/pgubook/ProgrammingGroundUp-1-0-booksize.pdf
Chapter 12. Optimization
-- چه وقت بهینه سازی کنیم؟
بطور کلی بهینه نکردن بهتر از بهینه سازی بیش از حد زود است. وقتیکه بهینه سازی میکنید، کد شما عموما ناواضح تر میشود، زیرا پیچیده تر میشود.
خوانندگان کد شما دردسر بیشتر برای کشف اینکه آنچه شما انجام داده اید را به چه علت انجام داده اید خواهند داشت که هزینهء نگهداری پروژهء شما را افزایش خواهد داد. حتی وقتیکه شما میدانید چطور و چرا برنامهء شما به روشی که انجام میدهد اجرا میشود، کد بهینه شده برای باگ زدایی و گسترش دشوارتر است. آن فرایند توسعه را به نحو قابل توجهی کند میکند، به هر دو علت زمانی که بهینه کردن کد میگیرد، و زمانی که تغییر کد بهینه شدهء شما میگیرد.
مکمل این مشکل این است که شما حتی از پیش نمیدانید مشکلات سرعت در برنامهء شما در کجا خواهند بود. حتی برنامه نویسان باتجربه در پیشبینی اینکه کدام بخشهای برنامه تنگه (bottleneck) هایی خواهند بود که به بهینه سازی نیاز دارند دچار دردسر هستند، بنابراین شما احتمالا در پایان با هدر دادن زمان خود برای بهینه سازی بخشهای نادرستی مواجه خواهید شد. ...
مادامیکه شما برنامه تان را توسعه میدهید، به داشتن اولویت های زیر نیاز دارید:
- همه چیز مستند شده باشد
- همه چیز همانطور که مستند شده است کار کند
- کد در یک شکل ماجولار و براحتی قابل تغییر نوشته شده باشد
مستندات اساسی هستند، بخصوص هنگام کار در گروهها. عملکرد مناسب برنامه اساسی است. شما متوجه خواهید شد که سرعت برنامهء کاربردی در هرجایی در آن لیست نیست. بهینه سازی در توسعهء اولیه به علتهای زیر لازم نیست:
- مشکلات سرعت کوچک معمولا میتوانند از طریق سخت افزار حل شوند، که اغلب از وقت یک برنامه نویس بسیار ارزانتر هستند.
- برنامهء کاربردی شما همانطور که شما آنرا مورد تجدیدنظر قرار میدهید به طرز قابل توجهی تغییر میکند، بنابراین بیشتر کوشش های شما برای بهینه سازی آن هدر میرود (بسیاری پروژه های جدید اغلب یک کد پایه دارند که همانطور که توسعه دهندگان دربارهء مسئله ای که آنها درحال تلاش برای حلش هستند بیشتر یاد میگیرند بطور کامل بازنویسی میشود. هر بهینه سازی انجام شده روی کد پایهء نخستین به کلی هدر رفته است).
- مشکلات سرعت معمولا در مکانهای معدودی در کد شما هستند - پیدا کردن آنها قبل از آنکه شما بیشتر برنامه را تمام کرده باشید دشوار است.
بنابراین، وقت بهینه کردن در انتهای توسعه است، وقتیکه شما مطمئن شده اید که کد صحیح شما عملا مشکلات کارایی (performance) دارد.
در یک پروژهء تجارت الکترونیک مبتنی بر وب که من در آن درگیر بودم، تماما بر روی صحت تمرکز کردم. این برای ناراحتی همکارانم که دربارهء این واقعیت که پردازش هر صفحه قبل از اینکه اصلا شروع به بار شدن کند دوازده ثانیه زمان میبرد (بیشتر صفحات وب در زیر یک ثانیه پردازش میشوند) خیلی سنگین بود. هرچند، من تصمیم گرفته بودم نخست آنرا به روش صحیح بسازم، و بهینه سازی را بعنوان یک اولویت آخر قرار دهم. وقتیکه کد پس از ۳ ماه نهایتا صحیح بود، پیدا کردن و برطرف کردن تنگه ها فقط سه روز طول کشید و میانگین زمان پردازش را به زیر یک چهارم ثانیه آورد. با تمرکز بر روی کد صحیح، من توانستم پروژه ای را که هم صحیح و هم کارا بود تمام کنم.
----------------------------------
م: تنگه (bottleneck) به بخشهایی از برنامه یا هر سیستمی میگویند که حاصل تمام بخشهای دیگر یا بازدهی نهایی سیستم تحت تاثیر آنست (بنوعی مجبور به گذر از آن است، و غیره) و بنابراین محدودیت اصلی کارایی برنامه در این بخش از برنامه قرار دارد که در موارد مشکل باعث افت کلی بازدهی سیستم به زیر حد مورد نیاز یا حد قابل تحمل میشود، باوجود اینکه در بخشهای دیگر برنامه/سیستم چنین محدودیتی وجود نداشته باشد یا حتی ظرفیت بالاتر از حد نیاز وجود داشته باشد.
======================
منبع:
Programming from the Ground Up
Jonathan Bartlett
Edited by
Dominick Bruno, Jr.
http://download.savannah.gnu.org/releases/pgubook/ProgrammingGroundUp-1-0-booksize.pdf
Chapter 12. Optimization