performance penalty for cross-assembly-calls?

[Peter Bär]

A Question to the C#/.Net Gods of this forum:


are there performance penalties when i compile (C#, FW1.1, ASP.NET,
Studio2003) a central baseclass in a different assembly than all the
derived classes?

f.i. ive got a class dbobject i project "Basesuppor t", compiles to
Basesupport.dll .
From dbobject i derive about 100 classes, thy all are located in Project
XYBiz, so they are compiled to XYBiz.dll.

doughter classes make heavy use of properties, methods and attributes
from the mother class (about 100 per method call)

Now, i dont know whether that design wouldnt produce a performance
penalty for jumping between user dlls, switching contexts, dlls,
whatever.

Approximation one aspx page (resulting in 1 database call(storeproc-
SQLserver)) uses 5 objects, 3 methodcalls each, with - as i said, about
100 cross-assembly-calls. Summed up, thats about 1500 cross-assembly-
calls.

Ok, i know, i know, "code is fast and db is slow, and therefor dont
think about performance, cause db is bottleneck anyways".

But i just wann aknow in principle whether there is no, just a tiny or
noticeable performance penalty from Framework & IIS, when they have to
ping-pong between two user-dlls 1500 times per page call...

Many thanks in advance &
cheers from Vienna

[Nicholas Paldino [.NET/C# MVP]]

Re: performance penalty for cross-assembly-calls?

Peter,

In the article on MSDN titled "Performanc e Tips and Tricks in .NET
Applications", located at (watch for line wrap):

http://msdn.microsoft.com/netframewo...etperftips.asp

It specifies that performance can be impacted if you don't keep your
working set small. Basically, if you load an assembly for the use of one
method on one object in it, you are going to incur a performance hit
(because you are bloating the type lookup information that is loaded into
the CLR).

However, if you need all of the classes in the assembly, then I wouldn't
see a reason to not do what you are doing. You won't have a problem with
switching contexts because that only happens when you switch threads, and
that isn't affected by how many assemblies you load.

Also, the assembly is loaded into memory and the type information is
stored in lookup tables in memory, so you don't have a boundary when
referencing things in another assembly. You might have another level of
indirection, but I believe it is negligible.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- nicholas.paldin o@exisconsultin g.com

"Peter Bär" <x@x.com> wrote in message
news:Xns93BADD4 492F07fiowenbvn 9u0wkfebkwe@213 .229.60.102...[color=blue]
> A Question to the C#/.Net Gods of this forum:
>
>
> are there performance penalties when i compile (C#, FW1.1, ASP.NET,
> Studio2003) a central baseclass in a different assembly than all the
> derived classes?
>
> f.i. ive got a class dbobject i project "Basesuppor t", compiles to
> Basesupport.dll .
> From dbobject i derive about 100 classes, thy all are located in Project
> XYBiz, so they are compiled to XYBiz.dll.
>
> doughter classes make heavy use of properties, methods and attributes
> from the mother class (about 100 per method call)
>
> Now, i dont know whether that design wouldnt produce a performance
> penalty for jumping between user dlls, switching contexts, dlls,
> whatever.
>
> Approximation one aspx page (resulting in 1 database call(storeproc-
> SQLserver)) uses 5 objects, 3 methodcalls each, with - as i said, about
> 100 cross-assembly-calls. Summed up, thats about 1500 cross-assembly-
> calls.
>
> Ok, i know, i know, "code is fast and db is slow, and therefor dont
> think about performance, cause db is bottleneck anyways".
>
> But i just wann aknow in principle whether there is no, just a tiny or
> noticeable performance penalty from Framework & IIS, when they have to
> ping-pong between two user-dlls 1500 times per page call...
>
> Many thanks in advance &
> cheers from Vienna
>[/color]