Сколько места занимают строковые константы в скомпилированной DLL?
Я пытаюсь понять, что влияет на скомпилированный размер моей сборки приложения Silverlight. Очевидно, что я хочу уменьшить размер моего приложения, и самый очевидный способ сделать это - избавиться от некоторых моих постоянных строк (например, строк ошибок-в приложении нет изображений или других ресурсоемких объектов). Впоследствии я буду тянуть строки с сервера по требованию. Прежде чем я пройду эту работу, я хочу выяснить, что приблизительная экономия пространства быть.
сколько памяти занимает скомпилированная константа в скомпилированной DLL? Я предполагаю, что он хранится как массив символов UNICODE UTF-16, и поэтому будет 2 байта на символ? Правильно ли это? Есть ли эмпирическое правило (или более строгое правило для вычисления того, сколько сжатия может быть сделано на строке для сжатия zip, которое используется для создания финала .xap файл?
EDIT очевидно, что некоторая путаница вызвана тем, как я задал этот вопрос. Я не говорю о "следе памяти" как "объеме памяти, потребляемом приложением", но размере " dll " и, следовательно, созданного файла xap.
3 ответов
скажем так: a System.Char (a char в c#) в .NET - 2 байта. Он не может представлять все символы Unicode. Только символы BMP (Basic Multilingual Plane) могут быть представлены одним Char. Остальные разбиты на суррогатные пары и нуждаются в 2xChar. В 99% случаев вы никогда не будете использовать символы за пределами BMP. http://en.wikipedia.org/wiki/UTF-16
сейчас... Strings в .NET состоит из System.Char (с NUL Терминатор в конце), поэтому это "нормально" 2 байта на символ BMP (плюс еще 2 символа для Терминатора).
в сборке строки сохраняются как UTF-16. Я только что проверил в Редакторе hex. Они не "полностью" NUL завершено (у них есть один байт при 0), но у них есть их длина (в байтах) + 1 (для одного байта при 0), добавленная как 16-битное значение.
уменьшить след памяти...] самый очевидный способ сделать это-избавиться от некоторых моих постоянных строк (например, строк ошибок), чтобы вытащить их с сервера по требованию.
объем памяти не зависит от размера исполняемого файла. У меня может быть исполняемый файл из нескольких K, который заполнит все ваши концерты ram.
Как вы думаете, создание сокета, запрос строки через какой-либо протокол, например HTTP, заполнение массива с только обязательными строками не будет свиней, по крайней мере, столько памяти, сколько просто массив строк, который компилируется в ваш исполняемый файл?
Если что, вы должны посмотреть в условной компиляции (#if ENGLISH // language specific variables here #endif) и, таким образом, включать только строки, которые вам понадобятся, или использовать один из многих вариантов интернационализации, как культур.
Если я правильно помню, UTF-8 обратно совместим с ASCII, что означает для большинства распространенных символов, это будет 1 байт на символ.