views:

669

answers:

3

I am looking for attributes I can use to ensure the best runtime performance for my .Net application by giving hints to the loader, JIT compiler or ngen.

For example we have DebuggableAttribute which should be set to not debug and not disable optimization for optimal performance.

[Debuggable(false, false)]

Are there any others I should know about?

+1  A: 

I found another: NeutralResourcesLanguageAttribute. According to this blog post it helps the loader in finding the right satellite assemblies faster by specifying the culture if the current (neutral) assembly.

[NeutralResourcesLanguageAttribute("nl", UltimateResourceFallbackLocation.MainAssembly)]
Lars Truijens
+1  A: 

And another: Literal strings (strings declared in source code) are by default interned into a pool to save memory.

string s1 = "MyTest"; 
string s2 = new StringBuilder().Append("My").Append("Test").ToString(); 
string s3 = String.Intern(s2); 
Console.WriteLine((Object)s2==(Object)s1); // Different references.
Console.WriteLine((Object)s3==(Object)s1); // The same reference.

Although it saves memory when the same literal string is used multiple times, it costs some cpu to maintaining the pool and once a string is put into the pool it stays there until the process is stopped.

Using CompilationRelaxationsAttribute you can tell the JIT compiler that you really don't want it to intern all the literal strings.

[assembly: CompilationRelaxations(CompilationRelaxations.NoStringInterning)]
Lars Truijens
Be careful with this, as not interning strings might actually hurt performance. Equality comparison for interned strings can be performed by simply comparing the references (pointers), which is much faster then comparing the string values.
csgero
True, but then you would have to write code that explicitly makes use of string interning. And since you can't count on literals to be interned you would have to do it yourself (String.Intern). The attribute mentioned here does not influence that.
Lars Truijens
+2  A: 

Ecma-335 specifies some more CompilationRelaxations for relaxed exception handling (so-called e-relaxed calls) in Annex F "Imprecise faults", but they have not been exposed by Microsoft.

Specifically CompilationRelaxations.RelaxedArrayExceptions and CompilationRelaxations.RelaxedNullReferenceException are mentioned there.

It'd be intersting what happens when you just try some integers in the CompilationRelaxationsAttribute's ctor ;)

Thomas Danecker