/
  • منطق صحیح بهینه سازی در برنامه نویسی

  • صفحه‌ها (2):
  • ارسال پاسخ   امتیاز موضوع:
    • 1 رأی - میانگین امیتازات: 5
    • 1
    • 2
    • 3
    • 4
    • 5

    حالت موضوعی | حالت خطی منطق صحیح بهینه سازی در برنامه نویسی
    نویسنده پیام
    vejmad آفلاین
    عضو ارشد
    *****

    ارسال‌ها: 1,460
    تاریخ عضویت: ۱۳۸۹ ارديبهشت ۲۱
    اعتبار: 23
    تشکرها : 484
    ( 1247 تشکر در 611 ارسال )
    ارسال: #1
    منطق صحیح بهینه سازی در برنامه نویسی
    بهینه سازی فرایند اجرای موثرتر برنامهء کاربردی شماست. شما میتوانید برای چیزهای زیادی بهینه سازی کنید - سرعت، مصرف حافظه، مصرف دیسک، غیره. اما ما در اینجا بر روی بهینه سازی سرعت معطوف هستیم.

    -- چه وقت بهینه سازی کنیم؟

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

    مادامیکه شما برنامه تان را توسعه میدهید، به داشتن اولویت های زیر نیاز دارید:

    - همه چیز مستند شده باشد
    - همه چیز همانطور که مستند شده است کار کند
    - کد در یک شکل ماجولار و براحتی قابل تغییر نوشته شده باشد

    مستندات اساسی هستند، بخصوص هنگام کار در گروهها. عملکرد مناسب برنامه اساسی است. شما متوجه خواهید شد که سرعت برنامهء کاربردی در هرجایی در آن لیست نیست. بهینه سازی در توسعهء اولیه به علتهای زیر لازم نیست:

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

    بنابراین، وقت بهینه کردن در انتهای توسعه است، وقتیکه شما مطمئن شده اید که کد صحیح شما عملا مشکلات کارایی (performance) دارد.

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

    ----------------------------------

    م: تنگه (bottleneck) به بخشهایی از برنامه یا هر سیستمی میگویند که حاصل تمام بخشهای دیگر یا بازدهی نهایی سیستم تحت تاثیر آنست (بنوعی مجبور به گذر از آن است، و غیره) و بنابراین محدودیت اصلی کارایی برنامه در این بخش از برنامه قرار دارد که در موارد مشکل باعث افت کلی بازدهی سیستم به زیر حد مورد نیاز یا حد قابل تحمل میشود، باوجود اینکه در بخشهای دیگر برنامه/سیستم چنین محدودیتی وجود نداشته باشد یا حتی ظرفیت بالاتر از حد نیاز وجود داشته باشد.

    ======================

    منبع:

    Programming from the Ground Up
    Jonathan Bartlett
    Edited by
    Dominick Bruno, Jr.
    http://download.savannah.gnu.org/release...oksize.pdf

    Chapter 12. Optimization
    __________________________________________________________________________
    God knows
    ۱۳۸۹ مرداد ۱۲ ۱۲:۲۲ عصر
    یافتن ارسال‌ها WWW پاسخ با نقل قول
     تشکر شده توسط : cyletech amir.s zoghal molana admin paull ali786 king_net Reza Rain7 Bojbaj voltan shgninc
    cyletech غایب
    علیرضا اسکندرپور شوفری
    *****

    ارسال‌ها: 2,243
    تاریخ عضویت: ۱۳۸۸ فروردين ۸
    اعتبار: 42
    تشکرها : 1258
    ( 2239 تشکر در 1089 ارسال )
    ارسال: #2
    RE: منطق صحیح بهینه سازی در برنامه نویسی
    بسیار ممنونم این می تونه شروع یک مقاله خوب برای بهینه سازی در برنامه نویسی باشد. اگر ترجمه (اگر شما مترجم بوده اید) را ادامه دهید لطف بزرگی به کاربران از جمله خودم و بروبکس ایران php می کنید Heart

    به امید موفقیت شما،
    علیرضا
    ۱۳۸۹ مرداد ۱۲ ۰۱:۳۳ عصر
    یافتن ارسال‌ها پاسخ با نقل قول
     تشکر شده توسط : molana paull Reza
    vejmad آفلاین
    عضو ارشد
    *****

    ارسال‌ها: 1,460
    تاریخ عضویت: ۱۳۸۹ ارديبهشت ۲۱
    اعتبار: 23
    تشکرها : 484
    ( 1247 تشکر در 611 ارسال )
    ارسال: #3
    RE: منطق صحیح بهینه سازی در برنامه نویسی
    بله خودم خیلی وقت پیش ترجمش کرده بودم و در فرومهای دیگه ای درج شده بود. اما اصل کتابش درمورد بهینه سازی نیست، فقط یک بخش کوچیک درمورد بهینه سازی داشت که فکر کنم (الان دقیقا یادم نیست) کمی خلاصه/گلچین هم کردم تا این متن رو ازش درآوردم. البته مسلما با پایبندی به امانت منظور و معنای مولف.
    کتاب خودش مفاهیم بنیادین برنامه نویسی و ساختار یک برنامهء exe و چگونگی اجرا و خیلی چیزهای جالب پایه ای دیگه رو با استفاده از زبان اسمبلی (البته تحت گنو/لینوکس) آموزش میده. همونطور که میبینید باوجود اینکه بیشترش اسمبلی هست اما درواقع سعی کرده یکسری مفاهیم پایه ای لازم در برنامه نویسی رو بصورت عمومی آموزش بده و طرف بنظرم برنامه نویس متبحر و باتجربه ای هست که با زبانها و فناوریها و در حیطه های مختلفی کار کرده.
    البته اینکه گفتم تحت لینوکس نترسید، روش کامپایل و اجرای برنامه هاش رو مشخص کرده و خیلی ساده هست؛ فقط تحت لینوکس هست دیگه! با نسخهء اسمبلی تحت لینوکس که یادگیری و درکش کار سختی نیست (شباهت بین اسمبلی های مختلف سیستم عاملهای مختلف خیلی زیاده) و کتاب خودش آموزش کامل داده.
    من درواقع دنبال یک مقدار یادگیری اسمبلی در حد پایه بودم که این کتاب رو انتخاب کردم (بخصوص که اون موقع روی لینوکس کار میکردم و ابزارهای اسمبلی و کامپایلر بصورت پیشفرض روی لینوکس هستن و کار کردن باهاشون خیلی راحته).
    __________________________________________________________________________
    God knows
    (آخرین ویرایش در این ارسال: ۱۳۸۹ مرداد ۱۹ ۱۰:۳۴ صبح، توسط vejmad.)
    ۱۳۸۹ مرداد ۱۹ ۱۰:۲۵ صبح
    یافتن ارسال‌ها WWW پاسخ با نقل قول
     تشکر شده توسط : paull
    vejmad آفلاین
    عضو ارشد
    *****

    ارسال‌ها: 1,460
    تاریخ عضویت: ۱۳۸۹ ارديبهشت ۲۱
    اعتبار: 23
    تشکرها : 484
    ( 1247 تشکر در 611 ارسال )
    ارسال: #4
    RE: منطق صحیح بهینه سازی در برنامه نویسی
    -- بزرگترین بهبود در پرفورمنس در میان تمام آنها وقتی است که یک سیستم از حالت عدم کارکرد به کارکرد میرود

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

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

    ==========================

    منبع: http://www.stanford.edu/~ouster/cgi-bin/sayings.php
    __________________________________________________________________________
    God knows
    ۱۳۹۰ فروردين ۲۱ ۰۹:۲۶ عصر
    یافتن ارسال‌ها WWW پاسخ با نقل قول
     تشکر شده توسط : cyletech paull ali786 mohsenkw
    admin آفلاین
    وحید سهرابلو
    **********

    ارسال‌ها: 5,734
    تاریخ عضویت: ۱۳۸۷ آذر ۲۴
    اعتبار: 100
    تشکرها : 1362
    ( 6196 تشکر در 3438 ارسال )
    ارسال: #5
    RE: منطق صحیح بهینه سازی در برنامه نویسی
    واقعا با این حرف آخر موافقم
    اینقدر نرم افزار برای بازیابی هست
    مثلا من نرم افزار نوشتم . بعد دیدم خیلی کند هست. با Zend Tracer کد رو تریس کردم و دیدم که چون از کانفیگ yaml استفاده کرده بودم و زیاد فای گانفیگ رو باز کرده بودم و پارسر زند و همینطور پارسر سیمفنونی برای پارس yaml خیلی کند عمل می کردن به .ini تغییر دادم و سرعت ۳ الی ۴ برابر بیشتر شد.
    به نظر من هرچقدر کدتون قابل توسعه تر باشه بهتر می تونید کدتون رو بهینه کنید.
    دریچه های بهینه سازی داخل نرم افزارهایی که قابلیت توسعه بالایی رو داشته باشن و OOP خوب داخلش رعایت شده باشه خیلی راحت پیدا میشه و با اعمال در یک قسمت قسمت عمده ای از برنامتون بهینه میشه.

    اما با این حرف در مورد mysql یه مقدار مخالفم. بهینگی داخل mysql اگر رعایت نشه فاجعه درست میکنه. هم توی طراحی و هم توی اجرا باید کاملا هواسمون به بهینه سازی باشه
    ۱۳۹۰ فروردين ۲۲ ۱۲:۴۶ عصر
    یافتن ارسال‌ها پاسخ با نقل قول
     تشکر شده توسط : vejmad cyletech paull ali786 mohsenkw
    vejmad آفلاین
    عضو ارشد
    *****

    ارسال‌ها: 1,460
    تاریخ عضویت: ۱۳۸۹ ارديبهشت ۲۱
    اعتبار: 23
    تشکرها : 484
    ( 1247 تشکر در 611 ارسال )
    ارسال: #6
    RE: منطق صحیح بهینه سازی در برنامه نویسی
    یک برنامه میتواند بهینه شود تا با سرعت بیشتری اجرا شود، یا با مصرف حافظه یا منابع دیگر کمتری، یا مصرف انرژی کمتری.
    سیستم بهینه شده معمولا تنها برای یک کاربرد یا مخاطب بهینه خواهد بود. در یک کاربرد که فضای حافظه ارزشمندتر است، ممکن است یک الگوریتم کندتر برای مصرف حافظهء کمتر انتخاب شود. اغلب یک طراحی بهینه برای همه جا و همه کار وجود ندارد. علاوه بر این، تلاش لازم برای بهینه ساختن کامل یک قطعه از نرم افزار تقریبا همیشه نسبت به منافعی که بدست خواهند آمد بیشتر از حد معقول است، بنابراین پروسهء بهینه سازی میتواند قبل از رسیدن به بهینه سازی کامل متوقف شود. خوشبختانه، اغلب اینطور است که بزرگترین بهینه سازیها در اوایل این پروسه پیش میایند.

    سطوح بهینه سازی:

    - سطح طراحی
    - سطح کد
    - سطح کامپایل
    - سطح اسمبلی
    - سطح زمان اجرا

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

    بهینه سازی ممکن است شامل یافتن یک تنگه (bottleneck) باشد؛ بخشی از کد که مصرف کنندهء اصلی منابع مورد نیاز است. اغلب قاعدهء Pareto اعمال میشود: 20 درصد از کد مسئول 80 درصد از نتایج است.

    در علم رایانه، قاعدهء Pareto میتواند با مشاهدهء اینکه 80 درصد از منابع معمولا توسط 20 درصد از عملیات استفاده میشوند، اعمال شود. در مهندسی نرم افزار، اینکه 90 درصد از زمان اجرای یک برنامه صرف اجرای 10 درصد از کد میشود (شناخته شده بعنوان قانون 90/10) اغلب تخمین بهتری است.

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

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

    چه وقت بهینه کنیم؟

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

    Donald Knuth دو عبارت زیر را درمورد بهینه سازی بیان کرد:

    1) ما باید افزایش کارایی های جزیی را فراموش کنیم، در 97 درصد اوقات: بهینه سازی زودهنگام ریشهء تمام چیزهای بد است.

    2) در قواعد جا افتادهء مهندسی یک بهبود 12 درصدی که به سادگی بدست بیاید، هرگز ناچیز شمرده نمیشود و من باور دارم که دیدگاه یکسانی باید در مهندسی نرم افزار حاکم باشد.

    م: توجه کنید که در عبارت دوم میگه بهبودی که به سادگی بدست بیاد. نه بهبودی که به سختی و با هزینه های قابل توجه از چیزهای دیگری بدست بیاد.

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

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

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

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

    --------------------

    بعضی اوقات زمان صرف شده برای بهینه سازی خودش میتواند یک مشکل باشد.

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

    -------------------

    نقل قولها:

    گناهان کامپیوتری بیشتر بنام کارایی انجام میشوند (بدون آنکه لزوما به آن دست یابند) تا هر علت دیگری - منجمله حماقت کورکورانه. W.A. Wulf

    ما باید کارایی های جزیی را فراموش کنیم، 97 درصد اوقات: بهینه سازی زودهنگام ریشهء تمام بدیهاست. اما ما نباید از فرصتهای خود در آن 3 درصد بحرانی صرفنظر کنیم. یک برنامه نویس خوب بوسیله چنان استدلالی دچار از خود راضی بودن نخواهد شد، او برای با دقت نگاه کردن به کد بحرانی عاقل خواهد بود؛ اما فقط پس از آنکه آن کد شناسایی شده است. Donald Knuth

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

    نخستین قاعدهء بهینه سازی برنامه: آنرا انجام ندهید. دومین قاعدهء بهینه سازی برنامه (فقط برای متخصصان): هنوز آنرا انجام ندهید. Michael A. Jackson

    ===============================================

    منبع: بخشهای گزیده ای از http://en.wikipedia.org/wiki/Program_optimization
    __________________________________________________________________________
    God knows
    (آخرین ویرایش در این ارسال: ۱۳۹۱ ارديبهشت ۶ ۱۱:۳۲ عصر، توسط vejmad.)
    ۱۳۹۱ ارديبهشت ۶ ۱۱:۰۶ عصر
    یافتن ارسال‌ها WWW پاسخ با نقل قول
     تشکر شده توسط : ali786 Y.P.Y admin Reza
    vejmad آفلاین
    عضو ارشد
    *****

    ارسال‌ها: 1,460
    تاریخ عضویت: ۱۳۸۹ ارديبهشت ۲۱
    اعتبار: 23
    تشکرها : 484
    ( 1247 تشکر در 611 ارسال )
    ارسال: #7
    RE: منطق صحیح بهینه سازی در برنامه نویسی
    بنظر من ساخت برنامه ای که از نظر منطق و الگوریتم و امنیت و امکانات بی نقص نباشه، اما پرفورمنس بالا داشته باشه، ارزش چندانی نداره.
    بعکس باید برنامه ای ساخت که از نظر منطق و الگوریتم و امنیت و امکانات (درحد نیازش) بی نقص باشه، بعد اگر پرفورمنس اون در عمل اونقدر پایین بود که مشکل جدی ایجاد کرد، اونوقت میشه روی بهینه سازی اون کار کرد، ولی بازهم نه اینکه برای بهینه سازی از کمال منطق و الگوریتم و امنیت اون بزنیم.
    نهایت نهایتش تنها اگر واقعا مجبور شدیم و هیچ راهی دیگری وجود نداشت باید این کار رو بکنیم که اون پارامترهای دیگر رو کم و بیش فدای امنیت کنیم.

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

    ولی الان اکثر برنامه نویسها برعکس فکر و عمل میکنن.
    و البته بنظر من خیلی هاشون اصلا این سواد رو هم ندارن که برنامه های بی نقصی بنویسن.
    فقط دلشون رو به این خوش میکنن که سرعتش رو تا میتونن بالا ببرن.

    اون شرایط خاص رو هم که شما گفتی خب خاصه دیگه. من منکرش نیستم. و اگر واقعا لازم بوده بخاطرش از کمال منطق و الگوریتم و امنیت برنامه بزنی، میتونیم جزو همون موارد اجباری که الان گفتم طبقه بندی کنیم. البته خوشبختانه این موارد زیاد پیش نمیان و اکثرا میشه بدون صدمهء جدی زدن به پارامترهای دیگر بهینه سازی هم کرد.
    ولی بعکس وقتی ما از اول این تفکر و رفتار اشتباه بهینه سازیهای وسواسی رو داشته باشیم، بیشتر وقتا بدون اینکه نیاز باشه از کمال منطق و الگوریتم و امنیت برنامه میزنیم. این تفکر و رفتار و تبلیغات/اغراق زیادی که در این زمینه هست باعث میشه اصلا افراد بجای تمرکز روی یادگیری خیلی چیزهای مفیدتر و این همه موارد دیگر پیشرفته و کاربردی ای که در علم رایانه و تخصص برنامه نویسی هست، وقت و انرژی زیادی روی این مسائل تلف کنن و هر روز دنبال نکته های بهینه سازی جزیی کم ارزش باشن. من این مسائل رو در این چند سال زیاد دیدم که دارم میگم.
    البته آدم باید بهینه سازی هم بلد باشه تا بجاش که نیاز شد استفاده کنه، ولی واقعا اونقدری هم بنظر من چیز پیچیده و گسترده و مهمترین چیز و اولین اولویت نیست در میان این همه مسائل و واقعیت هایی که هست.
    طرف میبینی کاراکتر به کاراکتر حرف از بهینه سازی میزنه، اما خیلی مسائل پایه ای و کاربردی و پیشرفتهء مورد نیاز رو درست و حسابی نمیدونه و/یا استفاده نمیکنه.
    این یک وسواس و اشتباهه بنظر من که سالهاست وجود داره.
    این همه گفتار و نصیحت از برنامه نویسان برجسته و دانشمندان مشهور برخلاف این رویه بوده تاحالا، اما همه نهایت میخونن و یه Thanks پاش میزنن، و در زندگی واقعی دوباره همون آش و همون کاسه. یعنی هیچ تغییر عملی مشهودی در این تفکر و روش بوجود نمیاد.
    __________________________________________________________________________
    God knows
    ۱۳۹۱ مهر ۳۰ ۰۱:۴۴ عصر
    یافتن ارسال‌ها WWW پاسخ با نقل قول
     تشکر شده توسط : ali786
    vejmad آفلاین
    عضو ارشد
    *****

    ارسال‌ها: 1,460
    تاریخ عضویت: ۱۳۸۹ ارديبهشت ۲۱
    اعتبار: 23
    تشکرها : 484
    ( 1247 تشکر در 611 ارسال )
    ارسال: #8
    RE: منطق صحیح بهینه سازی در برنامه نویسی
    پیرو بحثهایی که در تاپیک بهترین راه برای پیاده سازی سایت های چند زبانه داشتیم، میخوام چند مثال از بهینه سازیهایی که سرش اختلاف هست رو براتون بذارم.

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

    یک مثال دیگر هم اینه:

    من مثلا برنامه که مینویسم این یه مثال از چیزی که توی فایل کانفیگ خودم دارم:

    کد PHP:
    $password_reset_period=24*60*60//in seconds 

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

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

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

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

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

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

    پس چرا خیلی ها حتی موقعی که دارن با این زبانهای سطح بالا و برنامه نویسی سطح بالا کار میکنن، اینقدر به فکر مسائل سطح پایین فنی و بهینه سازیهای جزیی هستن، بدون اینکه در عمل نیاز و ضرورتشون پیش آمده باشه؟

    آیا این دو گفته و هدف، حداقل مقداری با هم مغایر نیستند؟

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

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

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

    بنده شخصا هیچ چیز عجیب و ناروشن و غیرمنطقی ای در این گفته ها نمیبینم.
    این عین منطق و معقول بودن است!
    در دنیای واقعی، چرا باید چطور دیگری فکر کنیم؟!
    اگر بازدهی واقعی حداکثری میخوایم، باید تفکر جامع بر اساس واقعیت هم داشته باشیم.
    اگر تعریف بازدهی حداکثری رو فقط پرفورمنس حداکثری بدونیم، اونوقت داستان عوض میشه، اما بدیهی است که داستان اینطور نیست! تمام دلایل و شواهد خلافش رو نشون میدن! غیر از اینه؟
    __________________________________________________________________________
    God knows
    (آخرین ویرایش در این ارسال: ۱۳۹۲ دي ۳ ۱۱:۵۸ صبح، توسط vejmad.)
    ۱۳۹۲ دي ۳ ۱۱:۵۶ صبح
    یافتن ارسال‌ها WWW پاسخ با نقل قول
     تشکر شده توسط :
    admin آفلاین
    وحید سهرابلو
    **********

    ارسال‌ها: 5,734
    تاریخ عضویت: ۱۳۸۷ آذر ۲۴
    اعتبار: 100
    تشکرها : 1362
    ( 6196 تشکر در 3438 ارسال )
    ارسال: #9
    RE: منطق صحیح بهینه سازی در برنامه نویسی
    من اسکریپت های متعددی رو که مشکل داشتن رو بهینه کردم. ولی باور کنید هیچ وقت به اینکه به جای
    $password_reset_period=24*60*60; //in seconds
    مقدار محاسبه شدش رو قرار بدم نرسیدم. بیشتر قسمتها سر سوتی های فاجعه امیز برنامه نویس قبلی و یا عدم استفاده از کش بوده.
    __________________________________________________________________________
    http://mydolphin.ir
    ۱۳۹۲ دي ۳ ۰۴:۲۱ عصر
    یافتن ارسال‌ها پاسخ با نقل قول
     تشکر شده توسط : vejmad
    vejmad آفلاین
    عضو ارشد
    *****

    ارسال‌ها: 1,460
    تاریخ عضویت: ۱۳۸۹ ارديبهشت ۲۱
    اعتبار: 23
    تشکرها : 484
    ( 1247 تشکر در 611 ارسال )
    ارسال: #10
    RE: منطق صحیح بهینه سازی در برنامه نویسی
    حالا یه مورد خیلی مخوف تر اخیرا در پروژم داشتم.
    اولا که دیگه چیزهایی مثل 24*60*60 یکی دوتا نیست و چندین و چندتاست:
    کد PHP:
    $autologin_ages=array(

        
    0,
        
    5*60,
        
    20*60,
        
    60*60,
        
    8*60*60,
        
    24*60*60,
        
    3*24*60*60,
        
    7*24*60*60,
        
    30*24*60*60,
        
    3*30*24*60*60,
        
    365*24*60*60,

    );

    $admin_autologin_ages=array(

        
    0,
        
    5*60,
        
    20*60,
        
    60*60,
        
    8*60*60,
        
    24*60*60,
        
    3*24*60*60,
        
    7*24*60*60,
        
    30*24*60*60,
        
    3*30*24*60*60,
        
    365*24*60*60,
        
    ); 

    دوما تازه این مقدارها بعد از محاسبه، با تابعی به متن هایی مثل «5 دقیقه»، «1 سال» و این حرفا تبدیل میشه و بصورت یک منو در فرم لاگین درج میشه.
    اگر میخواستم روی بهینه سازی وسواس باشم، باید میامدم اون تبدیل رو هم خودم انجام میدادم و نتیجه رو hard code میکردم که دیگه در هر درخواست نیازی نباشه تمام این محاسبات و تبدیلات انجام بشن.

    واقعا بد دردی هست «وسواس در بهینه سازی» که خیلی افراد دارن. چون اینطوری بجای اینکه بدن کامپیوتر براشون جون بکنه خودشون برای آسایش کامپیوتر بیل میزنن و جون میکنن!

    ما کامپیوترها را ساختیم تا بجای ما عملگی کنند، نه اینکه ما برای آنها عملگی کنیم!!

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

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



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

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

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

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

    پس شما باید فقط درمواردی دخالت کنید که واقعا در عمل مشکلی دیده میشه و معلومه که زبان و محیط اجرا نتونستن بطور خودکار پرفورمنس کافی رو بدست بدن. در این موارد بهرحال شما مجبورید خودتون بهینه سازی کنید. شاید هم اصلا الگوریتم شما مشکل اساسی داشته و خیلی ناشیانه بوده.
    __________________________________________________________________________
    God knows
    (آخرین ویرایش در این ارسال: ۱۳۹۲ دي ۷ ۰۱:۵۲ عصر، توسط vejmad.)
    ۱۳۹۲ دي ۷ ۰۱:۱۲ عصر
    یافتن ارسال‌ها WWW پاسخ با نقل قول
     تشکر شده توسط :
    « قدیمی تر | تازه‌ تر »

  • صفحه‌ها (2):
  • ارسال پاسخ
    پرش به انجمن:


    کاربرانِ درحال بازدید از این موضوع: 1 مهمان
    IranPHP.org | تماس با ما | بازگشت به بالا | بازگشت به محتوا | بایگانی | پیوند سایتی RSS