By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,673 Members | 1,302 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,673 IT Pros & Developers. It's quick & easy.

performance penalty for cross-assembly-calls?

P: n/a
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 "Basesupport", 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

Nov 13 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
Peter,

In the article on MSDN titled "Performance 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]
- ni**************@exisconsulting.com

"Peter Bär" <x@x.com> wrote in message
news:Xn**********************************@213.229. 60.102...
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 "Basesupport", 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

Nov 13 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.