بهینه سازی درون تابع
تحلیل

هدف از هر بهینه سازی اجرای برنامه تا حد امکان به صورت سریع است. مسئله اینجاست که این موضوع برای کامپایلر ممکن نیست که به صورت درست یک برنامه را تحلیل کند و مشخص کند این برنامه برای انجام چه کاری است و برنامه‌نویس چه قصدی از نوشتن این برنامه دارد. از طرف دیگر برنامه‌نویس‌ها با داشتن هدف از نوشتن برنامه شروع می‌کنند و برنامه ای را متناسب با آن می‌نویسند تا آن هدف را بدون پردازش اضافی برای پردازش محقق کنند.
به دلایل متنوع شامل خوانایی، برنامه‌ها به‌طور پیوسته به تعدادی روال و مراحل شکسته می‌شوند که حالت‌های کلی تر را رسیدگی کنند. اگرچه، عام بودن هر روال ممکن است منجر به تلاش اضافه و بیهوده برای کاربردهای خاص شود. بهینه سازی درون تابع تلاشی را برای این هدر رفت ارایه می‌دهد.
برای مثال تصور کنید که روالی وجود دارد که تابع F(x) را محاسبه می‌کند و برنامه در مکان‌های متفاوتی مقدار تابع F(6) را درخواست می‌دهد. محاسبه درخواست‌های دوم به بعد برای این مقدار در مکان‌های دیگر کاملاً غیر ضروریست. نتیجه می‌توانست با فرض اینکه تابع خالص باشد به جای آن ذخیره شود و در جاهای دیگر که تابع صدا زده شده بود به کار گرفته شود. این بهینه سازی ساده در صورتی که پیاده سازی تابع مورد نظر خالص نباشد درست نیست. برای مثال زمانی که تابع در اجرای خود ارجاعی به متغیرهایی به غیر از متغیر ورودی ۶ در مثال ما داشته باشد که در بین زمان صدا زدن تابع مقدار آن عوض شده باشد و اثرات حاشیه ای مثل چاپ کردن مقداری در لاگ، شمردن تعداد محاسبه‌ها، جمع کردن زمان گرفته شده از واحد کنترل مرکزی، آماده کردن جدول‌های داخلی برای ساده‌سازی، اجرای زیر دستورهایی برای متغیرهای مرتبط و …. از دست دادن این اثرهای حاشیه ای منجر به پذیرفتن مقدار خروجی برای دفعه‌های دیگر می‌شود.
در حالت عمومی تر، جدا از بهینه سازی‌ها، دلیل دوم برای استفاده از روال‌ها این است که از ایجاد کدهای اضافی و تکراری که خروجی یکسانی دارند جلوگیری کند. بنابر این یک رویکر عمومی برای بهینه سازی عکس عمل بالا به این صورت خواهد بود که: تعدادی یا همهٔ فراخوانی‌های خاص با کد مربوطه و پارامترهای مناسب جایگزین می‌شوند. سپس کامپایلر برای بهینه کردن خروجی تلاش می‌کند.
بهینه سازی کل برنامه(WPO) و بیهینه سازی زمان ارتباط(LTO)
“بهینه سازی کامل برنامه"(WPO) بهینه سازی کامپایلر یک برنامه با استفاده از اطلاعات مربوط به همه (ماژول (برنامه نویسی)|ماژول‌ها) در برنامه است. به طور معمول، بهینه سازی‌ها بر اساس [واحد ترجمه (برنامه نویسی) | در هر ماژول ، "کامپایل"] انجام می‌شوند. اما این رویکرد، در حالی که نوشتن و تست ساده‌تر و نیازمند تقاضای کمتری از منابع در حین کامپایل خود است، قطعیت در مورد ایمنی تعدادی از بهینه سازی‌ها مانند تهاجمی  درگیری را فراهم نمی‌کند و بنابراین نمی‌تواند آنها را انجام دهد حتی اگر آنها در واقع به دست آوردن عملکرد تبدیل می‌شوند که سمنتیک کد شیء منتشر شده را تغییر نمی‌دهند.
«بهینه سازی زمان پیوند» '(LTO) نوعی بهینه سازی برنامه است که توسط یک کامپایلر به یک برنامه در زمان پیوند انجام می‌شود. بهینه سازی زمان لینک در زبان‌های برنامه‌نویسی مرتبط است که برنامه‌ها را به صورت فایل به فایل کامپایل می‌کنند، و سپس آن فایل‌ها را به هم پیوند می‌دهد (مانند  C و فورترن)، به جای اینکه همه را با هم پیوند دهد. (مانند  جاوا تفسیر آنی (JIT)).
هنگامی که همه فایل‌ها به‌طور جداگانه به فایل شی (آبجکت فایل) تفسیر شدند، به‌طور سنتی، کامپایلر فایل‌های شی را به یک فایل واحد، اجرایی پیوند می‌دهد. با این حال، در LTO همان‌طور که توسط مجموعه کامپایلرهای GNU (جی‌سی‌سی: GCC) یا ال‌ال‌وی‌ام پیاده سازی شده‌است، مفسر قادر است نمایش میانی (جی‌سی‌سی bytod کد یا بیت کد LLVM) خود را در دیسک قرار دهد به گونه ای که تمام واحدهای مختلف مفسر که برای ساختن یک فایل اجرایی واحد به کار می‌روند، می‌توانند به عنوان یک ماژول واحد هنگامی که در نهایت اتفاق می‌افتد بهینه سازی شوند. این دامنه بهینه سازی‌های درون تابع را در بر می‌گیرد تا کل برنامه را شامل شود (یا به عبارت دیگر، هر آنچه در زمان پیوند قابل مشاهده است). با بهینه سازی زمان پیوند، کامپایلر می‌تواند اشکال مختلف بهینه سازی درون تابع را برای کل برنامه اعمال کند، و این امکان را برای تجزیه و تحلیل عمیق‌تر، بهینه سازی بیشتر و در نهایت عملکرد بهتر برنامه فراهم می‌کند.
در عمل، LTO همیشه کل برنامه را بهینه نمی‌کند - [کتابخانه (محاسبات) | توابع کتابخانه]، به ویژه  پیوند پویا اشیاء مشترک، به‌طور عمد برای جلوگیری از تکرار بیش از حد و قابلیت تغییر در زمان نگه داشته می‌شوند.  پیوند استاتیک به‌طور طبیعی به مفهوم LTO امانت داده می‌شود، اما فقط با بایگانی کتابخانه کار می‌کند که حاوی اشیاء IR است بر خلاف فایل‌های ماشین که فقط با فایل‌های شیء کار می‌کنند. با توجه به نگرانی‌های مربوط به عملکرد، حتی از کل واحد همواره به‌طور مستقیم استفاده نمی‌شود - یک برنامه می‌تواند به سبک تقسیم و تسخیر LTO مانند WHOPR GCC تقسیم شود.
و البته وقتی برنامه ای که ساخته می‌شود، خود یک کتابخانه است، بهینه‌سازی هر نمادی را که در دسترس خارجی (صادر شده) قرار دارد، نگه می‌دارد، بدون آنکه تلاش زیادی در از بین بردن آنها به عنوان بخشی از DCE داشته باشید.
شکل بسیار محدود تری از WPO هنوز هم بدون LTO امکان‌پذیر نیست، همان‌طور که توسط سوئیچ C | کد | -بعد برنامه-} GCC توضیح داده شده‌است. این حالت باعث می‌شود که GCC فرض کند که ماژول در حال تدوین شامل نقطه ورود (معمولاً main ()) کل برنامه است، به گونه ای که هر تابع دیگری در آن از بیرون استفاده نمی‌شود و می‌توان با خیال راحت ازبهینه شود. از آنجا که فقط به یک ماژول مربوط می‌شود، نمی‌تواند کل برنامه را در بر بگیرد. (می توان آن را با LTO به معنای یک ماژول بزرگ ترکیب کرد، وقتی پیوند دهنده در حال ارتباط برقرار کردن با GCC در مورد آنچه که از نقاط ورودی یا نمادها که از خارج استفاده می‌شوند)