.NET Compiler optimization and component updates

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

All,

This is a general question regarding how, and if, compiler optimization
techniques affect the general concept of being able to update a component of
an application without requiring a recompile of client code.

For example, suppose I have component: common.dll which defines several
constant values, say Const_A, Const_B and Const_C. Further say I have some
client code in another component: client.dll which references common.dll and
the constants defined within it. If I redefine the values of the constant
values and redeploy common.dll, will client.dll use the new values?

I encountered a situation like this in which client.dll did not use the
redefined constant values until I recompiled client.dll against the newer
version of common.dll.

I expect the compiler inlines the constant values for optimization, but does
this in someway break the concept of being able to modify and redeploy server
components without having to recompile client code? Also, what happens when
the compiler uses other optimization techniques like function inlining?

I guess my real question is when do I know it's safe to just redeploy
client.dll without needing to recompile client.dll?

I'm certainly not an expert in compiler construction or optimization so any
insight is appreciated.

Thanks,
Nick
 
Nick L. said:
This is a general question regarding how, and if, compiler optimization
techniques affect the general concept of being able to update a component of
an application without requiring a recompile of client code.

For example, suppose I have component: common.dll which defines several
constant values, say Const_A, Const_B and Const_C. Further say I have some
client code in another component: client.dll which references common.dll and
the constants defined within it. If I redefine the values of the constant
values and redeploy common.dll, will client.dll use the new values?
Click to expand...

If they're truly constants, declared as constants rather than static
readonly values, then it'll use the old values.
I encountered a situation like this in which client.dll did not use the
redefined constant values until I recompiled client.dll against the newer
version of common.dll.
Yup.

I expect the compiler inlines the constant values for optimization, but does
this in someway break the concept of being able to modify and redeploy server
components without having to recompile client code? Also, what happens when
the compiler uses other optimization techniques like function inlining?
Click to expand...

Inlining is done by the JIT compiler, not the language -> IL compiler.
I guess my real question is when do I know it's safe to just redeploy
client.dll without needing to recompile client.dll?
Click to expand...

Even in times when it's *safe* to redeploy just the library without
redeploying things compiled against it, I believe it would be *better*
to recompile everything. From what I remember about the file format,
there are "hints" in the file to say where methods in other assemblies
are likely to be, etc. It should work if they've changed location, but
slightly slower.

You should always recompile to check that the interfaces etc haven't
changed in an incompatible way, of course, but the choice of whether or
not to then redeploy is a tricky one. The interfaces may have changed
in a source-compatible but not binary-compatible way (eg you may have
changed a method from Foo(string s) to Foo(object o), and everything
will still recompile, but old programs will fail to link at runtime).
Then there's the constants problem you brought up.

I think things are slightly worse in the compact framework - I believe
there's a stronger tie there, and you *have* to recompile the
assemblies which depend on the changed assembly. (I've certainly seen
things fail for no good reason if that's not the case.)

As you can tell, I'm pretty conservative about this kind of thing,
myself...
 
Nick L. said:
All,

This is a general question regarding how, and if, compiler optimization
techniques affect the general concept of being able to update a component
of
an application without requiring a recompile of client code.

For example, suppose I have component: common.dll which defines several
constant values, say Const_A, Const_B and Const_C. Further say I have some
client code in another component: client.dll which references common.dll
and
the constants defined within it. If I redefine the values of the constant
values and redeploy common.dll, will client.dll use the new values?
Click to expand...

Keep in mind that C# code will be compiled to IL code at compile time (by
the C# compiler), and IL will be compiled to native code at runtime (by the
JIT):
Now, there is no representation for constants in IL code - the C# compiler
already translates them to their values.
I encountered a situation like this in which client.dll did not use the
redefined constant values until I recompiled client.dll against the newer
version of common.dll.

I expect the compiler inlines the constant values for optimization, but
does
this in someway break the concept of being able to modify and redeploy
server
components without having to recompile client code? Also, what happens
when
the compiler uses other optimization techniques like function inlining?
Click to expand...

Function inlining is done by the JIT, so this won't break anything.
I guess my real question is when do I know it's safe to just redeploy
client.dll without needing to recompile client.dll?
Click to expand...

This is more a rule of thumb: You can usually safely change private members
(unless you use binary serialization), change code (see below), and add new
members. AFAIK this is more or less the strategy MS uses for updates and
service packs.

Note that "you don't have to recompile" doesn't mean "you don't have to
re-test": Changing a method can *always* break client code if you change
pre- or postconditions, throw new exceptions or whatever. But doing this can
break client code if you recompile it, too.

Niki
 
Back
Top