Может __attribute __ ( (упаковано)) влияет на производительность программы?
У меня есть структура, которая называется журнал, который имеет 13 символов в нем. выполнив sizeof (log), я вижу, что размер не 13, а 16. Я могу использовать __attribute __ ((упакованный)), чтобы получить фактический размер 13, но мне интересно, повлияет ли это на производительность программы. Это структура, которая используется довольно часто.
Я хотел бы иметь возможность прочитать размер структуры (13, а не 16). Я мог бы использовать макрос, но если эта структура когда-либо изменяется, то есть поля добавляются или удаляются, я бы хотел, чтобы новый размер обновлялся без изменения макроса, потому что я думаю, что это подвержено ошибкам. Есть предложения?
4 ответа
Да, это повлияет на производительность программы. Добавление заполнения означает, что компилятор может использовать целочисленные инструкции загрузки для чтения данных из памяти. Без заполнения компилятор должен загружать вещи отдельно и выполнять битовый сдвиг, чтобы получить все значение. (Даже если это x86 и это делается аппаратно, это все равно нужно делать).
Подумайте: зачем компиляторам вставлять случайное неиспользуемое пространство, если это было не из соображений производительности?
Да, это может повлиять на производительность. В этом случае, если вы выделяете массив таких структур с атрибутом ((упаковано)) , большинство из них должно оказаться невыровненным (тогда как если вы используете упаковку по умолчанию, все они могут быть выровнены по 16 границы байта). Копирование таких структур может быть быстрее, если они будут выровнены.
Не используйте __attribute__((packed)). Если ваша структура данных находится в памяти, позвольте ей занимать свой естественный размер, определенный компилятором. Если она предназначена для чтения/записи на диск или с диска, напишите функции сериализации и десериализации; не просто храните на диске двоичные структуры, требующие вычислительной мощности. "Упакованные" структуры действительно не имеют никаких законных применений (или очень мало; см. комментарии к этому ответу для возможных несогласных точек зрения).
Да, это может повлиять на производительность. Как - зависит от того, что это такое и как вы это используете.
Невыровненная переменная может занимать две строки кэша. Например, если у вас 64-байтовые линии кэша, и вы читаете 4-байтовую переменную из массива 13-байтовых структур, есть шанс 3 из 64 (4,6%), что она будет распределена по двум линиям. Штраф за дополнительный доступ к кэшу довольно мал. Если все, что делала ваша программа, зависело от этой одной переменной, то 4,6% - это верхняя граница падения производительности. Если протоколирование составляет 20% рабочей нагрузки программы, а чтение/запись в эту структуру - 50% протоколирования, то вы уже на малой доле процента.
С другой стороны, если предположить, что журнал нужно сохранять, то уменьшение каждой записи на 3 байта сэкономит вам 19%, что означает много памяти или места на диске. Основная память и особенно диск медленные, поэтому вам, вероятно, будет лучше упаковать журнал, чтобы уменьшить его размер.
Что касается чтения размера структуры, не беспокоясь о том, что структура изменится, используйте sizeof. Как бы вы ни хотели делать числовые константы, будь то const int, enum или #define, просто добавьте sizeof.