В большинстве проектов я не вижу никаких флагов -Ox, которые вы считаете стандартными для каждый проект, так как он может значительно увеличить скорость программы.Есть ли причины для компиляции без оптимизации?
Есть ли какие-либо конкретные причины не компилироваться с помощью -Ox или это не-gcc-копии?
Откачать неоптимизированную программу гораздо проще, потому что объектный код имеет тенденцию быть более прямым переводом исходного кода. При включенной оптимизации компилятор может переупорядочить заявления или полностью их устранить, объединив несколько операций в один. Это означает, что при отладке программы (или дампа ядра) нет такого прямого отображения из позиции в образе программы в строку исходного кода.
GCC 4.8 добавляет новый уровень оптимизации, который является отличным компромиссом между производительностью и debuggability:
Новый общий уровень оптимизации,
-Og, был введен. Он учитывает необходимость быстрой компиляции и превосходный опыт отладки при обеспечении разумного уровня производительности во время выполнения. Общий опыт разработки должен быть лучше уровня оптимизации по умолчанию-O0.
С -Og компилятора делает простые оптимизации, которые не делают его более трудным для отладки и не займут слишком много времени для компиляции, так что код работает лучше, чем полностью unoptimised код, но все еще может быть отлажен.
Это делает Debug более точным без оптимизации.
Неиспользованные переменные, избыточные операторы не будут пропущены.
Одна из причин заключается в том, если вы хотите выполнить код с помощью отладчика. Если оптимизация включена, операторы могут быть переупорядочены или пропущены, а выполнение программы не обязательно будет следовать тому, что находится в исходном коде шаг за шагом. Значения переменных могут быть недоступны, поскольку они были оптимизированы. Таким образом, трудно понять, что делает программа, когда вы запускаете ее в отладчике.
Еще одна причина избежать оптимизации заключается в том, что вы использовали неопределенное поведение в своей программе, а оптимизация может привести к поломке вашей программы. (Фактически, это причина для с использованием оптимизации - чтобы найти такие ошибки.)
В несколько более старых проектах все наши тесты были выполнены с использованием отладочной сборки, включая множество заявлений печати. Для окончательной сборки, поставленной клиенту, было решено не использовать менее протестированную розничную сборку (с использованием полных опций оптимизации gcc), поскольку это может привести к проблемам, связанным с синхронизацией (на самом деле обнаружение дефектов теперь замаскировано из-за специфических время сборки отладки), и поскольку клиент был достаточно доволен текущей скоростью работы.
В моем текущем проекте большое количество кода должно быть помещено в ПЗУ (изначально: все), а затем мы, очевидно, не хотим удалять мертвый код, так как будущие обновления, которые будут размещены в ram, могут затем все еще используют код rom, уменьшая требования к пространству в ram.
Кроме того, что было бы по умолчанию? Оптимизировать пространство или время выполнения? Не выбор - единственный правильный выбор.