How much space do string constants occupy in a compiled DLL?

Question

I'm trying to work out what is affecting the compiled size of my Silverlight application assembly. Clearly, I want to reduce the size of my application, and the most obvious way of doing that is to get rid of some of my constant strings (e.g. error strings - there are no images in the application or other resource intensive entities). I will subsequently pull strings from the server on demand. Before I undergo this work, I want to work out what the approximate space savings would be.

How much memory does a compiled constant take up in the compiled DLL? I'm assuming it is is stored as a UNICODE UTF-16 array of characters, and so will be 2-bytes per character? Is this correct? Is there a rule of thumb (or more rigorous rule for calculating how much compression can be made on a string for the zip compression that is used to create the final .xap file?

EDIT There's clearly some confusion being caused by the way I've asked this question. I'm not talking about the 'memory footprint' as 'the amount of memory consumed by the application' but the size of the 'dll' and consequently the xap file that is created.

Answer 1

Let's say this: a System.Char (a char in c#) in .NET is 2 bytes. It isn't able to represent all the Unicode characters. Only the characters of the BMP (Basic Multilingual Plane) can be represented by a single Char. The others are split in surrogate pairs and need 2xChar. 99% of the times you won't ever use characters outside of the BMP. http://en.wikipedia.org/wiki/UTF-16

Now... Strings in .NET is composed of System.Char (with a NUL terminator at the end), so it's "normally" 2 bytes per character of the BMP (plus another 2 characters for the terminator).

In the Assembly, strings are saved as UTF-16. I have just checked with an hex editor. They aren't "fully" NUL terminated (they have a single byte at 0), but they have their length (in bytes) + 1 (for the single byte at 0) prepended as a 16 bit value.

Answer 2

reduce the memory footprint [...] the most obvious way of doing that is to get rid of some of my constant strings (e.g. error strings) with a view to pulling them from the server on demand.

The memory footprint is not dependent on your executable size. I can have an executable of a few K's that will fill up all your gigs of ram.

Do you think creating a socket, requesting a string through some protocol like HTTP, filling an array with only required strings will not hog at least as much memory as simply an array of strings that gets compiled into your executable?

If anything, you should look in conditional compilation (#if ENGLISH // language specific variables here #endif) and thus only include the strings you're going to need, or use one of the many options for internationalization like cultures.