How much space does string constants take in a compiled DLL?

Question

I am trying to figure out what affects the compiled size of my Silverlight application build. Obviously, I want to reduce the size of my application, and the most obvious way to do this is to get rid of some of my constant lines (for example, error lines - there are no images in the application or other resource-intensive objects). Then I will pull the lines from the server on demand. Before I begin this work, I want to find out what the approximate saving of space will be.

How much memory does the compiled constant execute in the compiled DLL? I assume that it is stored as a UNICODE UTF-16 character array and therefore there will be 2 bytes per character? It's right? Is there a thumb rule (or a stricter rule for calculating how many compressions can be performed in a line for zip compression, which is used to create the final .xap file?

EDIT. Obviously, some confusion is caused by the way I asked this question. I am not talking about the "amount of memory" as "the amount of memory consumed by the application," but about the size of the "dll" and, therefore, the xap file being created.

Answer 1

Let's just say: a System.Char (a char in C #) in .NET is 2 bytes. It cannot represent all Unicode characters. Only BMP (Basic Multilingual Plane) characters can be represented by a single char . The rest are separated by surrogate pairs and need 2x char . In 99% of cases, you will never use characters outside the BMP. http://en.wikipedia.org/wiki/UTF-16

Now ... The String in .NET consists of System.Char (with a NUL terminator at the end), so it "usually" 2 bytes per BMP character (plus 2 more characters for the terminator).

In the assembly, strings are saved as UTF-16. I just checked with a hex editor. They are not “completely” NUL complete (they have one byte at 0), but they have a length (in bytes) + 1 (for one byte at 0), added as a 16-bit value.

Answer 2

to reduce memory size [...] the most obvious way to do this is to get rid of some of my persistent lines (like error lines) in order to get them out of the server on demand.

The amount of memory does not depend on your executable file. I can have an executable file of several Ks that will fill all your ram concerts.

Do you think that creating a socket requesting a string through some protocol, such as HTTP, filling the array with only the required strings will not freeze at least as much memory as just an array of strings that compiles into your executable file ?

In any case, you should look at conditional compilation ( #if ENGLISH // language specific variables here #endif ) and, thus, include only those lines that you need, or use one of the many internationalization options, such as culture .

Answer 3

If I recall correctly, UTF-8 is backward compatible with ASCII, which means for most ordinary characters, it will be 1 byte per character.