Perf trade off: lots of small assemblies or fewer bigger assemblies??

re: Perf trade off: lots of small assemblies or fewer bigger assemblies??

Paul Tyng — Thu, 06 May 2004 14:01:00 GMT

Would there ever be a point where your working set size actually slows performance due to the amount loaded in which smaller assemblies would win out?

Also another question / comment:

In visual studio I find myself breaking out my functionality in to namespaces modeling the .Net framework ones (ie, collections, data, etc.). But I've also gotten in to the habit of breaking out my namespaces in to seperate assemblies so that I can utilize them in other solutions as well. Ideally all that I really need is a shared codebase and just share it between solutions since chances are they will be deployed with different versions of the shared assembly.

So what I'm curiuos about is do you think there it would be beneficial to still have project seperation in Visual Studio (ie, I have a Company.Collections project with all my collection code) but then have the solution compile in to a single assembly? That way I can get the performance benefits, but still have the project as unit of code thats shared between multiple solutions. What I fear is having to share the actual files from within sourcesafe in order to trim down my number of projects.

re: Perf trade off: lots of small assemblies or fewer bigger assemblies??

Joel Dolisy — Thu, 06 May 2004 15:03:00 GMT

Tools like VS.Net force you into the multiple assemblies scenario by the way they organize projects.
It would be good option of to be able to build one assembly out of multiple projects. I'm currious if you guys at MS use VS.Net for organizing your assemblies and builds?

re: Perf trade off: lots of small assemblies or fewer bigger assemblies??

Charlie Hensler — Thu, 06 May 2004 16:36:00 GMT

Here's a related issue:

I'm working in an environment where there are a lot of small web applications, done in both ASP an Cold Fusion, and where we are now moving to .NET, and implementing a build environment, including source control).

Traditionally, they have generally used very few vdirs, and placed an app's files in a sub directory under an existing vdir.

In .NET however, this doesn't really work, since we're no longer dealing with files and script, but with compiled code and the VS solution/project system. I guess the .NET corollary would be a single web project with unrelated "apps" divided up into folders, then compiled into one large .dll.

This seems less than ideal - for a simple change it would mean recompiling the entire "project", and redeploying the entire thing (including the huge dll). I shudder at the thought of artificially coupling a bunch of unrelated functionality in this way.

The alternative (which I prefer) seems to be to accept an increased number of vdirs containing individual apps (although I did find I could compile separate projects, but then deploy to a single vdir - just by deploying the separate .dll's to the vdir's bin folder. I decided against this though because it creates an odd deployment scenario).

I have no problem with many vdir's, but culturally here they don't like that idea (not exactly sure why not). The fundamental issue is moving from a scripted ASP environment (where a change to a single page can be made without a compile), to a (much better overall) platform where there is a compiled component.

Any thoughts?

re: Perf trade off: lots of small assemblies or fewer bigger assemblies??

Omer van Kloeten — Thu, 06 May 2004 16:59:00 GMT

http://blogs.msdn.com/junfeng/archive/2004/02/23/78139.aspx

Fewer Assemblies better.

Anatoly Lubarsky Blog — Thu, 06 May 2004 23:44:00 GMT

re: Perf trade off: lots of small assemblies or fewer bigger assemblies??

milbertus — Thu, 06 May 2004 22:06:00 GMT

Paul, one somewhat hacky solution to your problem is to link files in VS. When you add a file to a project, instead of clicking the Open button in the dialog, click the drop down arrow next to it, and select "Link File" (or something like that). Then, the file is still added to the project, however it won't be copied to the project's location, allowing the same physical file to be shared between projects.

Assembly architecture

Hendrik Swanepoel — Fri, 07 May 2004 10:04:00 GMT

re: Perf trade off: lots of small assemblies or fewer bigger assemblies??

Jiho Han — Fri, 07 May 2004 13:55:00 GMT

Paul,

I remeber there being a way to package multiple assemblies into a single assebly at deployment time. As I understood, you couldn't do this from VS.NET IDE but only using the SDK command line tools. That also goes for building your projects to a .netmodule instead of .dlls. VS.NET 2003 - as far as I know - doesn't support this.

I wonder whether whidbey addresses this problem...

re: Perf trade off: lots of small assemblies or fewer bigger assemblies??

Jeremy Marsch — Fri, 07 May 2004 15:00:00 GMT

What constitutes "lots" of assemblies? 5? 10? 100?

re: Perf trade off: lots of small assemblies or fewer bigger assemblies??

Naveen Karamchetti — Thu, 20 May 2004 08:19:00 GMT

I guess 10+ would mean lots of assemblies.

Fewer Assemblies better

Anatoly Lubarsky: T-SQL Weblog — Tue, 08 Feb 2005 04:26:00 GMT

C vs C# (more specifically internal vs friend)

greg::blog — Fri, 01 Jul 2005 08:20:16 GMT

C vs C# (more specifically internal vs friend)

greg::blog — Fri, 01 Jul 2005 08:20:33 GMT

C vs C# (more specifically internal vs friend)

greg::blog — Sat, 02 Jul 2005 18:32:51 GMT

Project anti-pattern: Many projects in a Visual Studio Solution File

Chad Myers' Blog — Wed, 16 Jul 2008 04:17:58 GMT

I've been hearing from several colleagues about how their Visual Studio solution files have many

Brad Abrams Perf trade off lots of small assemblies or fewer bigger | debt solutions

Fri, 19 Jun 2009 20:14:54 GMT

PingBack from http://debtsolutionsnow.info/story.php?id=11700