задание в Lippman'e



Путаюсь в догадках  . Четких критериев по которым можно было бы отдать предпочтение одному из вариантов не вижу.
Помогити, аргументируя please.

По мне, так когда ответ находишь сам, то всё же приятнее и пользы больше. Лучше прочти главу ещё раз, а если и тогда не догадаешься, то приходи - расскажем;)

предположения конечно имеются :

а) массив
    1. потому что знаем размер
    2. с набором будем работать локально

б) vector
     не известно кол-во счетов и можно использовать vector::push_back()

в) динамический массив
    1. знаем размер
    2. удобно передать указатель

но не уверен ...

boriska, ты получаешь приз за правильный ответ возьми его на верхней полке

а я бы вектор использовал... его не нужно уничтожать вызывающей ф-ции (в отличие от дин. массива)...

зато работает медленнее, и возможно неэффективно использует память.

  слишком голословно...

почему?

std::vector<myType> v (elem_size)... да и vector::reserve никто не отменял

помещение в вектор ф-ия значит уже медленнее, а также вся манипуляция идет через высокоуровненвые механизмы это опять же временные затраты.
да и если бы вектор был действительно лучшим по всем параметром, он бы давно стал заменой new\delete а этого не происходит..
дополнительные усилия

vector классный массив он лучше чем array В языке высокого уровня
Python массивы имеют примерно такую же природу что vector

Вернее строка там есть список,
и типов нет или есть,   
скорость конечно это аргуметнт , но что уж при нынешних скоростях
этот параноидальный скоростной погоня за скорост

Это сообщение отредактировал(а) apook - 21.4.2007, 17:54

конкретно, в чём затраты?
скажем так: чем по (трудо-, время-)затратам отличаются записи v[i] и a[i], если v - vector, a - массив, созданный при помощи new.

это просто удобная обёртка... тож самое, что сказать, что, "если бы streams были бла-бла-бла, то *printf/*scanf давно бы заменили"...


конечно... когда используют new, размер массива не указывают - он сам догадывается...

ну и в итоге... vector и ещё раз vector!

неа, но мы получаем что vминус new только в операции удаления, а это уже не смертельно

я не знаю как реализован этот оператор, поэтому про него ниче не скажу, а вот push будет раьотать полюбому медленнее.

стандарт принуждает его работать так же... (inline ф-ций, определённых в классе + отсутствие нужды на проверки границ при использовании оператора - этим он и отличается от vector::at)...

а кто заставляет использовать push, если в нём нет нужды (объём массива заранее известен)?


не совсем понял как это относится к дополнительным усилиям...
точнее, ты сейчас сказал, что для вектора усилий нужно меньше (не нужно напрягаться об удалении)

результат new\delete - 1572
результат вектора - 26432, думая дальнейший спор не уместен, а преимущество более чем в 10 раз, само за себя говорит. 
компилилось в VS2003, дебаг 

Хм, а у меня (gcc 4.1.2) результаты:
вектор: 3750 без оптимизации, 630 с -O2
new/delete: 1000 без оптимизации, 450 с -О2
Получается верктор только в 1,4 раза медленее, имхо если не нужно выжимать последние миллисекунды - самое то.

если release то 1400 и 700, но все равно разница ощутима. и это хороший аргумент в пользу new

разница получается из-за того что при

время тратиться на создание временного объекта, инициализацию этим объектом, а потом удаление его.

Даже при
 
у меня натикало 11968, а вариант с динамическим выделением - всего 890   

g++-3.4.2+stlport-5.1.3 в релизе(про дебаг отдельно) даёт 234 против 343 (vector и new соответственно)...  
насчёт дебага: прелесть контейнеров в том, что, в дебаг-режиме они проверяют всё на логические ошибки... к примеру, если после изменения контейнера использовать итератор, полученный до этого изменения, то он(итератор) кинет исключение(smart-iterator), в релизе же даже не пикнет(fast-iterator)...

насчёт менеджера памяти: изначальный вариант я не поленился запустить 25 раз (только new, vector даже пробовать не стал)... каждый раз результат был всё меньше и меньше, причём, разрыв между первым запуском и последним был чуть ли не в 10 раз... короче говоря результат сильно зависит и от менеджера памяти и от операционной системы и от объёма оперативной памяти...

Ничего там не тратится, это же не конструктор копирования.

Оптимизацию включи  
Скорость нужно проверять на релизной сборке, потому что именно она будет потом использоваться.

НЕ ВЕРНО. 
Запись vector<int> (50000) создает вектор из 50000 ПРОИНИЦИАЛИЗИРОВАННЫХ элементов.



Это сообщение отредактировал(а) Mayk - 21.4.2007, 19:31

кстати, ещё одна "мелочь": вектор имеет инициализированные значения (0)... отсюда и разница такая... а вот как объяснить, что в цикле записи вектор работает быстрее чем дин-массив я затрудняюсь... но говорит это только в его пользу 

Добавлено через 40 секунд
Mayk, опередил 

nickless - за второе замечание спасибо
а по поводу 

готов спорить....
to Mayk -   



Это сообщение отредактировал(а) boriska - 21.4.2007, 19:38

Я вообще имел ввиду 
и

Какой именно временный объект там создаётся? int?

То что вектор инициализирует память, с этим я не спорю.

то что он инициализируется "это его проблемы", тесты закончились у всех поразному, у меня new дало двойной прирост памяти.
так что я остаюсь при своем мнениии.

Vector нужен, когда количество элементов заранее не известно. Точка.


Увеличение скорости даже на 10% иногда очень важно. А уж в данному случае, когда прирост 50-100%...


В обертках, кроме того, могут использоваться дополнительные переменные для удобства реализации остальных функций.


вот... иногда инициализация такая не нужна.


Ну а тут и ты не прав... Кто же в дебаге скорость проверяет? Инлайнинг функций-то в дебаге не производится... как минимум. А, уже сказали до меня по этому поводу...
А вообще по ходу поддерживаю. Если размер заранее известен, то даже 50% прирост скорости весьма существенен. Векторное - векторному.
В данном случае использовать вектор ради всего лишь автоматического удаления... имхо, не то.

50000000 Это слишком большое число для масивов, т.к. время работы зависит от свободной памяти, распределение страниц, виртуальной памяти и т.д.
У меня на VS 2005 1 раз вектор работал 2сек, 2 раз около 1,5 все последущие 0,7 сек.
Масив 0,5 сек.
Привиду свой тест:

Вектор: 1,7сек
Масив: 1,5сек

Вектор немного отстает, но если им правильно пользоваться то отставание не большое - максимум процентов 20-35.
ИМХО во всех программах особо не чуствительных к скорости лучши пользоваться вектором. Кроме того вектор непожирает лишнюю память, и не инициализирует обьекты пока они не нужны.
Например зачем нам иметь масив из 100000 обьектов (причем все будут инициализированы), если мы пользуем в 80% тока 100.

Это сообщение отредактировал(а) Lomir - 21.4.2007, 23:46

Офигеть... ты посты выше читал? Цитату об определение вектора и инициализации?
Вектор память лишнюю не пожирает? Да чтобы сделать операцию добавления элемента квазиконстантной по времени, он всегда резервирует какой-то процент от текущей запрошенной памяти...

Намного быстрее объявить 1000000 элементов сразу без инициализация, чем потом 20 раз перераспределять и/или выделять поблоково эти данные.

Массив динамический вообще не инициализирует память...


Вообще говоря, это немало. Кроме того - это если действительно умело пользоваться. Если не очень умело, то цифра может заметно возрасти. Кроме того, как уже писали выше, поведение вектора более дерганое при выделении, и тут еще менеджер памяти может чего-то фигачить...

Lomir, ты не понял... push_back мы не используем... мы ставим и вектор и new в равные условия - заранее сообщаем длину массива и используем оператор [] для доступа к эдементам...

ммм... про прирост памяти ты умолчал...

насчёт "его проблемы" - если я не ошибаюсь, то эта "проблема" решается путём смены аллокатора (второй шаблонный параметр вектора...)

угу, а то, что при доступе к объектам скорость +30% (хотя, я это объяснить не могу) тебя не смущает...


кому точка... кому нет... лично я везде, где это возможно юзаю стандартные контейнеры и ничуточку не сожалею...


из-за 4-40 байт ты готов пожертвовать всеми этими прелестями?

а, что, если от неё можно избавится? ;)


ну и в заключении: кто-нибудь может объяснить то, что доступ к элементам для вектора быстрее, чем для массива созданного с помощью new?

Достаточно прикольный спор получился.
Мне кажется что-то не так - ведь вектор изнутри организован стандартными функциями.

Я уже в свое время проводил тест: какой доступ быстрее через указатель или через скобки.
Скобки оказались ощутимо быстрее. Но этот результат получился только при приближении задачи к реальной - вставке дополнительных команд в цикл. Ведь в реальности нет задач просто прогнать цикл по массиву без каких-либо действий.

Мне кажется, что в векторе очень хорошо используются регистровые переменные для настройки оптимизатора. Так как тест проводился в голом виде - просто индексация, то вектор и показал с оптимизатором себя быстрее. На самом деле время доступа у массива и вектора не должно отличаться - так как они используют одинаковые механизмы. В живой задаче, где между изменениями индекса будут находиться другие команды, которые не позволят оптимизатору сохранить регистры вектор должен быть медленнее априоре - так как у него обязательно будут дополнительные механизмы обслуживания сервиса.

ИМХО:
Для большинства задач вектор подходит идеально, но как любая универсальная штуковина она просто ОБЯЗАНА съедать больше ресурсов - за удобство надо платить. 
В задачах, где рессурсы критичны, собственное хранилище данных несомненно будет более экономичное. Любой мастер своего дела (в любой специальности) имеет как наборы стандартных инструментов, так и собственные приспособления, с помощью которых он достигает лучшего результата. Так и в программировании. Так что правы все стороны.   

да как в принципе такое может быть? что может быть быстрее доступа (прямого) по памяти? (на user-уровне).
Не верю. Разве что кэширование какое-нибудь, блин... причем хитро, очень хитро работающее...



Геморрой, имхо. В массиве ничего дополнительно делать не надо.



Какими? Автоматическое удаление? В данном случае - выделки не стоит.


выложи полный код еще раз (если он изменился), на котором ты получил +30%. А я у себя проверю... что получится.

тьфу..описался я не памяти ,а скорости

Согласен с Lomir'ом на счет размера массива: он должен быть не слишком большим, чтобы не сказывалось обращение к свопу. Только в его варианте нужно вместо push_back обращаться к элементам по индексам. Тогда скорость работы вектора и массива будут совершенно одинаковыми (с учетом статистических погрешностей) - проверено на VS 2003.

И в конце концов, если мы гонимся за эффективностью и не хотим отказываться от удобств, предоставляемых вектором, кто мешает обращаться с ним, как с массивом? 

господа, ткните пальцем, где дополнительные механизмы!
точнее они есть, но если их не использовать (работать так же как и с массивом)

кеширование? шутишь? это же не жесткий диск...

вектор - тоже геморрой... но он уже готовый... точно также как и готовые в boost пулы... также, как и этот аллокатор, который можно сделать один раз и не парится

универсальность хотя бы... ну это каждому по вкусу...


щёлк

А что, в векторе нет контроля выхода за пределы индекса?

только в методе at(size_t)

есть, но не во всех методах, например в operator[] нет, а в at() есть.

Она не обязана  быть в []. Но МОЖЕТ присутствовать в отладочных версиях.

Вектор является ведь шаблонным классом.
И когда идет вызов переменной типа Vector - то передается как минимум 2 адреса: самого объекта и функции, которую необходимо вызвать. Соответственно - вот дополнительный сервис.

И вообще спор этот с моей точки зрения абсолютно бессмысленен.
Вектор ОБЯЗАН быть медленнее - только потому, что это высокоуровневый объект (класс). Со всеми вытекающими отсюда  накладными расходами - код дополнительных методов и т.п. 
Отсюда же следует, что вектор ОБЯЗАН быть удобнее - на то это и есть высокоуровневый объект.

Мне стало интересно - я слегка модернизировал приведенный тест - так, чтобы он всетак ближе был к реальности.
Я избрал такой вариант:


Специально сделал массив небольшим, помешал оптимизатору вовсю использовать регистровые переменные, режим включил релизный.
Если отбросить отклонения из-за сторонних процессов (специально сделал несколько проходов), то вектор однозначно отстает от массива.

Я и так был в этом уверен на 99% (чудес на свете не бывает), но тут в обсуждении все по-разному говорили, вот я и решил сам посмотреть.
В среднем массив быстрее вектора примерно на 20% и это абсолютно нормально.


Это сообщение отредактировал(а) Anikmar - 22.4.2007, 18:24

Не стоит обобщать свой опыт на все компиляторы и все оптимизаторы.


Как мы видим, всё совсем не так однозначно.

Абсолютная неправда.

Добавлено через 1 минуту и 1 секунду

а inline?

я уже говорил выше, что IS принуждает компилятор ф-ции, определённые внутри класса далеть inline... соответственно ничего никуда не передаётся и нету нигде накладных расходов...

А что такие цифры огромные?

На самом деле я не обобщаю на все компиляторы, я взываю к здравому смыслу. 
Вектор написан на Си и использует абсолютно такую же технологию как и голый массив - это же шаблон! И где-то там внутри сидит оператор доступа к массиву - его можно посмотреть под отладчиком:

  const_reference operator[](size_type __n) const { return *(begin() + __n); }

Только чтобы получить значение по этому адресу - как минимум происходит вызов функции ( вонкретном случае оператора [])
И нельзя заставить вектор быть быстрее голого массива - он ведь призван сделать массив удобнее - так как является надстройкой над стандартным массивом.

Конкретные тесты на скорость на самом деле достаточно условны: разница между командами - несколько десятков тактов процессора, и на таких небольших величинах заемтна особо не будет.

Как у меня:
В режиме отладки вектор медленее массива в 2 раза
В режиме без оптимизации - медленнее примерно на 2%
В режиме с оптимизацией - примерно 20%
Можно для интереса запустить на всю ночь, но совершенно нет никакого интереса этим заниматься.

Просто бессмысленный спор - вот и все. Я на форуме обратил внимание, что многие очень болезнено реагируют на любые попытки критики STL (на себе в свое время изучил)
Я не критикую  STL - а просто объяаляю факт: вектор слегка медленнее, но удобнее. И спорить с этим просто бессмысленно - так как даже в некоторых описаниях STL это прямо говориться.

что такое "IS"? И как оно "принуждает"?

В любом учебнике по Си сказано, что inline функция увеличивает скорость, но в качестве накладных расходов - использует  дополнительную память. Поверьте, даром ничего не бывает - если где-то прибавилось (в данном случае удобства) - значит где-то убавится (в данном случае скорости и памяти). Не понимаю, зачем так болезненно это воспринимать?   

На этом, я пожалуй раскланяюсь - спор ни о чем. Пустое.

В этой фразе явно видно непонимание сути inline. Что такое "дополнительная память"?
Как раз случай с вектором, это прямое доказательство ложности данного высказывания.

Это сообщение отредактировал(а) Daevaorn - 22.4.2007, 18:57

В том-то и фишка, что в С++ многие вещи даются "даром" (ну или почти), чего не скажешь о многих других языках. В этом и заключается его сила. По-сути, целью создания языка С++ было создание высокоуровневого ОО-языка, не уступающего в производительности языку Си. Именно С++ впервые показал, что ООП не обязательно должно быть дорогим удовольствием.

Код программы тоже в памяти находится, если вы забыли.
inline функция - это функция, непосредственно встраиваемая в код программы. Этим самым уменьшается время на передачу параметров, но увеличивается размер программы и занимаемая ей ПАМЯТЬ

Daevaorn имел в виду, что в данном случае нет дополнительного расхода памяти по-сравнению с обычным массивом. Кстати, это хорошо видно из ассемблерного листинга.

Это сообщение отредактировал(а) likehood - 22.4.2007, 19:28

Угу. Только оператор [] вектора транслируется в 1-2 машинные команды — куда меньше, чем запихивание параметров в стек, вызов, выполнение операции и возврат.

Все возможные причины, по которым вектор может быть медленнее, уже перечислили. operator [] к ним не относится.

Таак, теперь подумай, если тот код который скрывается за vector::operator[] встроить в место вызова(нет ни передачи параметров, нет вызова функции, нет создания фрейма стека, нет передачи результата), то что получится? Правильно, сокращения расхода "памяти" и соответсвенно увеличение скорости. Вот так вот. Посмотри, кстати, asm листинг и прозрей

А если вызовов 20?
Мы же сравниваем не просто однострочную iniline функцию с вызовом через стек и вызовом inline?

Мы сравниваем конкретную функцию inline с командой непосредственно взятия данных из массива. Эта inline функция практически это и делает! Посмотрите на ее код - я же ее привел. И сравните с кодом a = b[i].

Добавьте туда код остальных методов вектора (даже если ими не пользоваться (кстати, а зачем тогда вектор, правда?) - они что, в воздухе висят? Теперь добавим, что у нас есть вектор int и вектор float - 2 совершенно разных класса скомпилятся. Со всем своим функционалом (которым можно не пользоваться).

Полноте - чудес на свете не бывает, еще раз повторю. Просто к памяти сейчас отношение такое - типа ее много. И получаем операционки, которые на ядро 512 требуют - зато все удобно. Раз схалявил - два схалявил и получаем экзешники по 10 метров с функционалом, "которым необязательно пользоваться".

likehood,  Daevaorn,

Я немного не понимаю суть спора: неужели вы серьезно считаете, что функционал STL не потребляет дополнительных ресурсов? С чем вы спорите? 
Мое мнение: STL удобна, но расплачиваться приходится некоторым перерасходом ресурсов (памяти, скорости или того и другого).
Ваше мнение: Ни фига - этот функционал ничего не пожирает, он достается даром. Т.е. все килобайты исходного кода STL - это все ерунда и ни памяти ни времени процессора она не отнимает.

Продолжать дискуссию я просто не вижу смысла. 

За удобства надо платить. И это закон жизни, а не только программирования. Отсюда правда вытекает еще один лозунг: надо постараться не платить за неудобства - это уже ближе к программированию.

прошу показать где происходит перерасход ресурсов на примере.
vimdiff запущенный на исходники даёт такую картину



По мне так эти асмовые исходники примерно эквивалентны. Основной цикл так вообще один к одному.

Это сообщение отредактировал(а) Mayk - 22.4.2007, 21:07

а какая разница сколько, с каждого inline'a экономим.

мы сравниваем доступ к элементу

ну и где тогда по твоему проигрывает вектор?

а ты знаешь сколько кода генерирует компилятор, допустим, для создания массива не из элементов POD типа? Для вызова деструкторов и т.д. Так что на этом фоне при POD типе в векторе, теряем минимум. А при не POD типе, ещё больший минимум

Неа. Компилятор осуществляет merge'инг. Ну например метода vector::size(). И многих других

Программы делают люди и для людей, поэтому критерий "удобно" в этом случае приоритетный.

Мы говорим про доступ к элементам. Ты же всячески уходишь от темы в "общую" болтовню

Mayk, у вектора на три машинных инструкции больше  

  
Vyacheslav(извини если исковеркал), что призван показать твой пример, что для использования вектора в этом контексте надо заюзать еще одну строку кода, так это ему не в плюс..

??? Вот те раз. Посмотрите мои посты. Я как раз и написал в первый раз - общее свое мнение о шабонных классах. 
И то что на моем компиляторе вектор по скорости слегка отстал - это факт, я его просто зафиксировал и написал об этом.

Последние посты - были как раз общие - теоретизировали на тему рессурсов:







Mayk, посмотрите заодно размеры получившихся файлов, если использовать массив и вектор. А по поводу практической идентичности листингов - про это я уже сказал, чем вы хотите меня удивить? вектор ведь тоже на СИ++ написан:



А поповоду незначительноя разницы уже было:





Много пены - мало толку.   

разница сосавляет 371 байт. После strip'а она уменьшается до 296 байтов.


371 байт и 3 машинные инструкции (не входящие в основной цикл процедуры) являются величинами на несколько порядков меньшими чем заявленные



что свидетельствует о преувеличении тормознутости и гигантности stl. 


Это сообщение отредактировал(а) Mayk - 22.4.2007, 21:55

Про какие величины я, простите, упоминал? Про "незначительные"? Или про "несколько десятков тактов (не команд)" процессора? А как я их должен еще охарактеризовать? А про 20% выигрыш в скорости на моем тесте - что имею, то и имею. Можно говорить, что Билдер плохо оптимизирует работу STL, столько же на сколько другой компилятор плохо оптимизирует работу массивов. Это все вода. Поймите главное: STL написана на том же языке! используя те же команды. Это не другой компилятор, не некая сторонняя библиотека - это шаблоны! И компилируются они одновременно с вашим кодом. И если утверждать на 100% - что STL работает быстрее, это то же самое, что говорить - никто не напишет лучше, чем разработчики STL. А ее писали такие же программисты (и может быть пользовались теми же форумами). Именно поэтому STL может быть медленнее стандартных средств, такая же по скорости, но никак не быстрее (если брать уровень программиста одинаковый). Потому, что одни и те же механизмы языка используются. 

А на счет экзешников по 10 метров - это мое обобщенное отношение к современным подходам. Почем линуксоиды не любят форточников? Одна из причин именно - за это. Линукс при том же функционале работает на полном барахле. Там код вылизывают и лишнего не вешают.

На счет килобайтов исходного кода STL.
Да, тут я погорячился. Посмотрел исходники. Их не килобайты. Их Мегабайты. Ну тут уж извиняйте.


Покажите хоть один мой пост, где я назвал STL тормознутой и гигантской? Максимум, что я говорил - это о некоторой потери рессурсов. И это чистая правда, хоть что тут сделай. За исключением разве что результатов теста - там я оговорил четкие цифры, которые выдала конкретно моя машина с конкретно моим компилятором.

Можно, конечно еще поспорить на эту тему - например, посчитать такты процессора для каждой команды и т.п.
Использовать не тепличный бессмысленный тест, а более рабочую программу. все равно результат будет такой-же. Программист всегда будет выбирать: написать быстрее, но готовыми средствами, или изобрести свой велосипед. В некоторых случаях последнее дает ощутимые результаты, а в некоторых нет. Все зависит от задачи и от головы. Можно использовать вектор как в приведенном последнем тесте или "не используя его функционал" - непонятно зачем тогда. А если пользоваться всей мощью вектора - тогда платить придется точно. А так спор близок к теме: кто больше бензина жрет мопед или мерседес. Если их отправить накатом с горки - поверьте одинаково. Но в реальной жизни речь идет не о бензине. Если надо ехать из Питера в Москву - то уж естественно на мерседесе. А если через пробки смотаться в магазин за два квартала - то мопед. ИМХО.

БАЯН. Давайте его заканчивать!   

Темка, однако, полезная... закрепить бы ее на будущее

Всем отписавшимся респект!   

Кэширование оперативной памяти в кэш процессора, я имел в виду.

   Тема тут, конечно, успела еще 2 страницы постов нагрести 

жесть, сколько настрочили... всё не асилил...

ничего не происходит... сколько раз уже это повторить?

International Standard (Programming languages - C++, ISO-IEC, IS-14882, Second edition, 2003-10-15)
слово принуждает в Ожегове посмотри, плз ;)


"дополнительной" памяти нужно ровным счётом столько же, сколько понадобится, если написать то же самое, только в самом коде... короче говоря, дополнительного там ничего нет!



которое работает только с STL-контейнерами?  


Это сообщение отредактировал(а) archimed7592 - 23.4.2007, 19:10

Я не про слово спрашивал, а про его суть в том конкретном контексте в котором оно было написано. По этому самому стандарту, который ты привел, "принудить" компилятор не может даже слово inline.
Так что уход от ответа, это не очень хороший стиль разговора;)

ааа... ты об этом 
ну если компилятор соответствует Стандарту и ф-ция может быть заинлайнена, то это произойдёт... я это имел ввиду...

  конечно!   это хитрые интеловцы/амдэховцы (нужное подчеркнуть) специально в процессор встраивают коды, которые, увидя в бинарнике код, сгенерированный на основе stl-евских кодов, включают супер-пупер оптимизацию...

А если серьезно, то у нынешних процессоров кэши обоих уровней и конвейера настолько не поддаются систематиации, то вполне могло быть и такое.
Да! В твоих тестах - чей тест первым запускался - вектора или массива?

Добавлено через 2 минуты

кажись, все-таки нет.
inline - в стандарте, как уже говорили - всего лишь рекомендация. Формально компилятор имеет полное право этого не делать. Кажись, по стандарту.

ну дык... рекурсию хоть укакайся не заинлайниш... потому и в рекомендательном виде (хотя, совр. компиляторы оч хорошо рекурсию разворачивают)...

во всех вариациях 

не, это понятно. В плане, компилятор, всего лишь   поддерживающий стандарт, может вообще плевать на функции, которые он в принципе может заинлайнить.

Вот хороший компилятор, поддерживающий стандарт, конечно, из ресурсов системы выбьется, но сделает все, что сможет 

Да ладно вам. Inline, конечно, рекомендательный характер носит, но это не значит, что компилятор будет на него плевать, если хочет (при соответствующих опциях, конечно). Просто это зависит от контекста. Например, куча вложенных вызовов и все хотят быть inline. Так что у бедного компилятора регистры из ушей вылезают...  Поэтому ему и разрешено самому определять, что тут инлайнить, а что нет. И угадать это сложно. А в тривиальных случаях - можно не сомневаться, сделает. Если мы говорим не наколенном компиляторе от Вася Пупкин и Со.
Поэтому лучшие друзья программиста - профайлер с отладчиком.