Какое влияние (если есть) переход Delphi 2009 на Unicode (/ UTF16) оказывает на размер исполняемого файла и объем памяти?
Вот один из раздела "Никаких вопросов не слишком глупо":
Ну как говорит сабж: есть ли удар? Если да, то сколько? Будут ли теперь все строковые литералы в моем коде и в моих ресурсах DFM занимать вдвое больше места внутри скомпилированных двоичных файлов? Как насчет использования памяти времени выполнения скомпилированными приложениями? Все ли строковые переменные теперь будут занимать вдвое больше оперативной памяти? Стоит ли мне вообще беспокоиться?
Я помню, как что-то подобное мне задавали во время одной из ранних предварительных веб-трансляций, но я не могу вспомнить ответ. И поскольку пробная версия составляет всего 14 дней, я не собираюсь просто пробовать ее, пока не обновят нужные мне сторонние библиотеки (предположительно, примерно через месяц).
DFM поддерживает UTF-8 уже много лет. Строки Unicode могут быть закодированы как UTF-8 или UTF-16.
Переменные UnicodeString во время выполнения будут занимать в два раза больше оперативной памяти во время выполнения, да. AnsiString, UTF8String и другие переменные на основе Ansi не будут.
Реми, почему бы вместо этого не опубликовать эти комментарии в качестве ответа?
Ответы 4
Я не использовал Delphi много лет, но это, вероятно, зависит от того, какую кодировку Unicode они используют. UTF8 будет точно таким же для обычного набора символов ASCII (он использует только более одного байта, когда вы переходите к экзотическим символам). UTF16 может быть немного раздутым.
UTF-16 обычно меньше для языков, не основанных на латыни.
D2009 использует UTF-16 в качестве строкового типа по умолчанию, хотя при необходимости вы можете сделать переменные UTF-8.
Ян Гойвертс обсуждает компромисс между размером и скоростью в хорошем сообщении в блоге.
Строковые литералы в DFM используются в кодировке UTF-8 по крайней мере с D7. Следовательно, не будет увеличения размера из-за строк в DFM с D2009.
Я слишком много лет ждал Unicode VCL, наконец, мы его видим. Я не думаю, что большинству приложений нужно беспокоиться о размерах, поскольку у них в любом случае не так много строковых литералов или они хранят огромные объемы данных в памяти.
Вопросы удобства использования более важны, чтобы максимально оправдать использование Unicode.
Если какой-то разработчик хочет создать крошечных бывших, они могут вручную оптимизировать с помощью AnsiString (если i18n не является проблемой).
Я наконец-то получил в свои руки Delphi 2009, и после внесения необходимых корректировок мой проект теперь компилируется и работает нормально. :)
Чтобы быстро получить результаты, мне сначала пришлось закомментировать один немного более сложный модуль приложения, поэтому он еще не сопоставим на 100%, но уже кажется достаточно безопасным, чтобы предсказать это, несмотря на значительное количество строковых литералов в нашем исходном коде (чрезмерное количество сообщений журнала отладки ) размер двоичного файла, скомпилированного с помощью Delphi 2009, вероятно, будет примерно таким же, как и раньше, если не меньше!
Интересно, действительно ли компилятор Delphi выполняет какое-либо сжатие двоичных файлов или, по крайней мере, его разделов ресурсов? Я действительно ожидал, что изменение строковых литералов UTF-16 окажет большее влияние на это конкретное приложение. Действительно ли литералы хранятся внутри двоичного файла как (несжатый) UTF-16?
У меня еще не было времени исследовать различия в объеме памяти.
Обновлено: Не напрямую связан с Unicode, но определенно связан: Андреас Хаусладен недавно опубликовал интересную информацию о (значительном) влиянии параметра компилятора {$STRINGCHECKS} (BTW: включено по умолчанию) на размер скомпилированного исполняемого файла: http://andy.jgknet.de/blog/?p=487
Нет, он не сжимает двоичные файлы или их ресурсы. Для этого вы должны использовать внешний сторонний компрессор, например UPX. Строковые литералы, присвоенные переменным UnicodeString в коде, будут храниться как UTF-16 (и как UTF-8 при назначении переменных UTF8String, Ansi при назначении переменных AnsiString и т. д.).
Строковые литералы, используемые в коде, будут интерпретироваться в контексте, в котором они фактически используются, и затем будут соответствующим образом закодированы в исполняемые данные. Другими словами, если у вас есть строковый литерал, назначенный для AnsiString, он будет закодирован как Ansi. Если у вас есть литерал, назначенный UTF8String, он будет закодирован как UTF-8. Если у вас есть литерал, назначенный UnicodeString, он будет закодирован как UTF-16.