.NET Internal Workings

[Howard]

I've taken out a portion of my main code and put it in a seperate dll
libaray.

My question is would there be any performance hit by referencing a dll
library as suppose to all in one exe?

Thanks
Howard

[Mattias Sjögren]

My question is would there be any performance hit by referencing a dll
library as suppose to all in one exe?

Probably nothing significant.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Nothing to lose the sleep for.
--
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

"Howard" <ho*******@yahoo.com> wrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...

I've taken out a portion of my main code and put it in a seperate dll
libaray.

My question is would there be any performance hit by referencing a dll
library as suppose to all in one exe?

Thanks
Howard

[Ben Voigt]

"Howard" <ho*******@yahoo.com> wrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...

I've taken out a portion of my main code and put it in a seperate dll
libaray.

My question is would there be any performance hit by referencing a dll
library as suppose to all in one exe?
It all gets JIT compiled the same either way.

Best: put only the minimal startup code in your .exe, so you can get going
as quickly as possible (put up a splash screen, start listening to sockets,
or whatever -- this is one legitimate reason for breaking/weakening
encapsulation). Although static constructors don't run until the code in
question is referenced, PEVerify has to analyze the whole assembly unit at
once. Put trusted code in a separate assembly, signed with strong name, and
use GAC, so that PEVerify won't have to run each time -- it caches results
and as long as the assembly isn't modified, it can skip reverification.
WIth unmanaged, use locality to help segment your application (code in the
same library should be used together, to minimize the working set)... I
don't know how this would apply to managed code -- because it gets JIT
compiled, it probably improves locality a lot.

Thanks
Howard

[chanmm]

There must be a purpose to split the code. Are you following so of the
patterns here:
http://msdn.microsoft.com/practices/topics/patterns/

chanmm
"Howard" <ho*******@yahoo.com> wrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...

I've taken out a portion of my main code and put it in a seperate dll
libaray.

My question is would there be any performance hit by referencing a dll
library as suppose to all in one exe?

Thanks
Howard

[Rob R. Ainscough]

It's all interpreted so not really any hit. If you want to improve
performance you'll need to see what is slow (coding technique wise) and
modify accordingly. Avoid using Object type if you can (especially in any
repetative tasks).

"Howard" <ho*******@yahoo.com> wrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...

I've taken out a portion of my main code and put it in a seperate dll
libaray.

My question is would there be any performance hit by referencing a dll
library as suppose to all in one exe?

Thanks
Howard

[Howard]

Do you know of any good articles on good and bad programming practices in
..NET and c#?

"Rob R. Ainscough" <ro*****@pacbell.net> wrote in message
news:O0**************@TK2MSFTNGP04.phx.gbl...

It's all interpreted so not really any hit. If you want to improve
performance you'll need to see what is slow (coding technique wise) and
modify accordingly. Avoid using Object type if you can (especially in any
repetative tasks).

"Howard" <ho*******@yahoo.com> wrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...

I've taken out a portion of my main code and put it in a seperate dll
libaray.

My question is would there be any performance hit by referencing a dll
library as suppose to all in one exe?

Thanks
Howard

[Jon Skeet [C# MVP]]

Rob R. Ainscough <ro*****@pacbell.net> wrote:

It's all interpreted so not really any hit.
No, none of it is interpreted.

<snip>
Avoid using Object type if you can (especially in any
repetative tasks).

Care to go into details about that? I *suspect* you're suggesting that
excessive boxing/unboxing should be avoided, but it's not clear.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Cor Ligthert [MVP]]

Jon,

Beside boxing do you see that often VB programmers take direct the object
for everything while there is no problem to use direct the right class,

They rely on the late building (reflection) method build inside VBNet.

Probably something that comes from VBS.

Cor

"Jon Skeet [C# MVP]" <sk***@pobox.com> schreef in bericht
news:MP************************@msnews.microsoft.c om...

Rob R. Ainscough <ro*****@pacbell.net> wrote:

It's all interpreted so not really any hit.

No, none of it is interpreted.

<snip>

Avoid using Object type if you can (especially in any
repetative tasks).

Care to go into details about that? I *suspect* you're suggesting that
excessive boxing/unboxing should be avoided, but it's not clear.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Cor Ligthert [MVP] <no************@planet.nl> wrote:

Beside boxing do you see that often VB programmers take direct the object
for everything while there is no problem to use direct the right class,

They rely on the late building (reflection) method build inside VBNet.

Probably something that comes from VBS.

I'd say that's another reason to turn Option Strict On more than
anything else :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too