Инлайн может не только чутка добавить к скорости. Скажем, взять memcpy: три аргумента, с которыми функция начинает разбираться, типа выровнены указатели или невыровнены (и на какую границу -- 4 байта, 8 байт, 16 байт?), какой степени двойки кратен size, и тд и тп, после чего возможно, границы подравниваются -- происходит часть копирования невыровненным алгоритмом, потом запускается выровненный алгоритм, с максимальной пропускной способностью на остальное. Если ты вызываешь memcpy на килобайт данных, то я не удивлюсь, если эти проверки будут выполняться дольше, чем собственно копирование. (Впрочем, я не проверял, я из самых общих соображений о том, что условия ведут к сбоям конвееров, а сбои конвееров очень дорогие.)

Если memcpy заинлайнить, что часть этих проверок (а может и все проверки) компилятор сможет выполнить в процессе компиляции, может быть развернёт циклы, и де факто при копировании килобайта, ты можешь получить, что-нибудь в стиле 16 итераций цикла, в каждой из которых по 4 пересылки данных через sse, каждая из которых идёт в свой собственный конвеер, и сбой конвеера происходит ровно один раз, при завершении цикла.

Это 80-х и 90-х, когда компиляторы были тупые, инлайнить имело смысл только чтобы избежать накладных расходов на вызов функции, сегодня же, когда gcc и llvm очень глубоко анализируют код, всё стало гораздо интереснее. И это используется активно для того, и чтобы более мелко дробить код на человеку удобные куски, и чтобы писать generic (не в смысле полноценных дженериков, а в смысле на общий случай заточенные) реализации алгоритмов, которые потом оптимизатором доводятся до специально заточенной под случай реализации.

Сегодня логика такая, что чем большие куски кода ты соберёшь inline'ом в единый AST компилятору на оптимизацию, тем больше ты можешь получить бонусов от оптимизации. И поэтому, сегодня, мало уметь в ассемблер, чтобы писать быстрый код -- надо изучать свой компилятор, регулярно компилируя в асм, глядя какие оптимизации он в состоянии провести, а какие нет.