Мы с вами говорили, что код не может быть просто быстрым или медленным,
он может быть достаточно или не недостаточно быстрым для задачи, которую он решает.
Давайте рассмотрим пример: у нас есть программа,
которая функцией main вызывает функцию generateBigVector и выводит на экран его размер.
Функция generateBigVector устроена достаточно просто,
она объявляет результирующий вектор,
добавляет в него каким-то образом 28 тысяч строк и возвращает этот результирующий вектор.
Давайте скомпилируем нашу программу,
вот она компилируется и запустим ее, замерив время работы.
Для этого я перейду в консоль,
в который, я значит нахожусь в папке,
где лежит мой проект,
перехожу папку debug, и здесь есть файл coursera.exe,
это собственно исполняемый файл программы,
которую я только что скомпилировал,
и давайте мы замерим время работы нашей программы.
Мы запустили её и ждем.
Программа выполнилась.
Она вывела на экран 28 тысяч,
это собственно размер нашего вектора,
и мы видим, что программа работала 4.3.
Ну кажется, что для программы,
которая делает вектор из 28 тысяч строк, это как-то долго.
Все таки современный компьютер уже достаточно мощный,
чтобы решать эту задачу гораздо быстрее, и мы понимаем,
что наша программа работает слишком медленно,
и нам надо найти почему,
что в нашей программе надо ускорить,
чтобы она работала быстрее.
Как мы это можем сделать?
Ну мы можем воспользоваться интуицией.
Например, можем рассуждать так։ функция
generateBigVector формирует вектор из 28 тысяч строк
и возвращает этот вектор через return,
может возникнуть лишнее копирование и наверное из за него наша программа тормозит.
Хорошо, давайте с этим как-то поборемся и напишем другую версию нашей функции,
которая принимает вектор посылки и не
будет выполнять лишнего копирования.
Вот она принимает посылки, наполняет его,
и давайте теперь запустим обновленную версию,
generateBigVector result, вывести result
size, компилируем, компилируется, отлично.
Давайте снова запустим с замером времени и мы ожидаем,
что сейчас у нас все будет летать.
Запускаем программу, и что-то она опять долго работает.
Даже давайте так, чтобы быть абсолютно уверенным,
что мы нигде не ошиблись,
пусть вторая версия нашей программы наполняет вектор 32 тысячами элементов,
чтобы мы точно знали,
что нужная функция вызывается,
мы правильный файл запускаем.
Вот, значит запустили, ждём, ждём, ждём-ждём.
На экран вывелась 32 тысячи,
значит мы правильную функцию запустили и она отработала 5,6 секунды.
О чём нам это говорит?
Это говорит о том, что интуиция нас подвела. Мы ожидали,
что у нас там лишнее копирование и из за него наша программа работает медленно,
но это оказалось не так.
Я специально привел этот пример.
Чтобы навести вас на второе правило оптимизации кода,
который звучит очень просто, замеряйте!
А если интуиция, которую мы используем для
поиска узких мест в программе часто оказывается неверна и она субъективно,
то измерение, они объективны и они
позволяют нам действительно увидеть то место в программе,
из за которого она работает медленно.
Давайте мы последуем этому совету,
давайте мы откроем снова нашу программу,
уберем вторую версию функции generateBigVector вернем,
здесь как было, компилируется, и давайте померим.
Давайте померим, сколько работает вся наша программа и померим,
сколько работает тело функции main.
Мы уже с вами еще в белом поясе по С++ писали код измерения,
вот давайте, когда изучали константные ссылки, давайте его повторим.
Значит, мы запоминаем, когда наша программа начала работать и