Design efficiency

[Gregory Gadow]

This is a very arcane question, but I'm going to ask it anyway: Is there a performance hit by having a method in a separate assembly? I am designing a website with custom providers. Passwords will be hashed, which means my hashing routine will be used A LOT. Ideal design would be to put the method in the utility assembly, where it could be accessed by both the MembershipUser and MembershipProvider modules. Would giving these modules their own copy of the method noticeably improve performance, or would the nuisance of having two methods that must remain identical outweigh any improvement?

[Jose Amilcar Casimiro]

Strictly from a performance point of view, one assembly is always better than several assemblies. Each assembly loading has a fixed overhead. For multiple assemblies, you pay the overhead several times. The overhead of assembly loading at minimum includes the following: 1. Finding the assembly. 2. Loader in memory data structure tracking this assembly. 3. Assembly initialization. Possibly could be a problem of cold start. From a design point of view, duplicate code is a bad choice.

[jschell]

Gregory.Gadow wrote:

Passwords will be hashed, which means my hashing routine will be used A LOT.

I sort of doubt that. Only way that would occur is if you required the password on every single request (not session.) Not to mention of course that this would suggest that you think that the time for this process is at least significant if not the biggest factor in the request. And regardless the impact of the call itself is going to be trivial compared to the cost of actually doing the hash.

Gregory.Gadow wrote:

Is there a performance hit by having a method in a separate assembly?

If you have profiled your application using real message process flows and determined that calling semantics themselves are significant then you probably want to write everything in C++ and create one massively statically linked application. Myself I doubt that you can measure the normal calling semantics in any application that isn't anything other than a benchmark in all of the major languages. And it won't be significant. There are of course ways to produce non-normal calling semantics for instance if you dynamically loaded a module for every single method call (unloading it each time) then I would expect that to be measurable. And very, very likely to be a bad design as well.

[Lost User]

This is more of a paranoid situation of having to decide between performance and maintainability. Been there, done that :-)

Gregory.Gadow wrote:

Is there a performance hit by having a method in a separate assembly?

Obviously, there is. But it would be only when the Assembly is loaded for the first time. And if accessing another class has already loaded the said assembly, then you do not even have to worry about it. If you carefully set the Base DLL address of each of your assemblies in the order they're likely to load and the size of the assemblies, you can actually slightly increase the load time (although this will most probably be unnoticeable)

Gregory.Gadow wrote:

would the nuisance of having two methods that must remain identical outweigh any improvement?

Remember DRY. Having multiple copies of code actually results in a lot of maintenance headache that does not justify the performance improvement, if any.

[Kornfeld Eliyahu Peter]

Gregory.Gadow wrote:

separate assembly

In IIS every assembly embeds a penalty added to the start-up time of your website, however after this start-up it's not an issue anymore.

Gregory.Gadow wrote:

Ideal design would be to put the method in the utility assembly

Not exactly true. Good design only says that, that function should be written once, but it does not violate the design rules to compile the very same code into several assemblies if it proved to have a good impact on performance...

Gregory.Gadow wrote:

their own copy

Not copy but a linked source...

I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)