Re: .NET Compiler optimization and component updates

From: Nick L. (NickL_at_discussions.microsoft.com)
Date: 10/09/04 

Date: Sat, 9 Oct 2004 13:35:24 -0700

Thanks Jon, I appreciate your feedback; it has been very helpful.

"Jon Skeet [C# MVP]" wrote:

> Nick L. <NickL@discussions.microsoft.com> wrote:
> > 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?
>
> 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?
>
> 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?
>
> 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...
>
> --
> Jon Skeet - <skeet@pobox.com>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too
>

Relevant Pages

  • Re: .NET Compiler optimization and component updates
    ... > 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. ... > this in someway break the concept of being able to modify and redeploy server ...
    (microsoft.public.dotnet.general)
  • .NET Compiler optimization and component updates
    ... techniques affect the general concept of being able to update a component of ... an application without requiring a recompile of client code. ... I expect the compiler inlines the constant values for optimization, ...
    (microsoft.public.dotnet.general)
  • Re: .NET Compiler optimization and component updates
    ... > This is a general question regarding how, and if, compiler optimization ... > an application without requiring a recompile of client code. ...
    (microsoft.public.dotnet.general)
  • Re: Unidata upgrade
    ... you should check whether there have been any improvements in compiler ... optimization between versions ... if that is so you should recompile and your system may run faster ... Prev by Date: ...
    (comp.databases.pick)
  • Re: Unidata upgrade
    ... > you should check whether there have been any improvements in compiler ... > optimization between versions ... I would always recompile everything immediately. ... Prev by Date: ...
    (comp.databases.pick)
Quantcast