Condividi tramite

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

  • Articolo

Over the internal CLR perf alias someone asked about what yields better performance having lots of small assemblies or a few of big ones… I thought I’d you’d find the comments from the team interesting...

As Rico would say, nothing is 100%, you have to measure, but the census of the CLR perf folks is that fewer bigger assemblies are better.

Lot of assemblies in the managed world is bad for the same reason lot of dlls are bad in the unmanaged world. The OS has a per-dll cost which is reduced by combining assemblies.  In addition, inlining can be more aggressive within an assembly

The biggest reason that assemblies are expensive is because we try very hard to make everything else ‘light’. Thus we try to push everything that can be shared to the assembly level that we can (thus it is shared among all classes in the assembly). Similarly, we try to optimize class loading at the expense of assembly loading, since we expect more class loads. If you have lots of small assemblies, you ruin this heuristic.

Assemblies are also the unit of enforcing security. Thus when doing cross assembly calls inlining is more constrained.

You are also fighting the OS heuristics. The File system is very good at prefetching data that is contiguous, however if you have lots of DLLs, they are not likely contiguous, which means disk moves, and significant loss of startup time.

Also, because of compatibility issues, changing assembly boundaries is painful. Thus it is worth some time ‘up front’ to insure that you can live with your present setup for a very long time.

Comments

  • Anonymous
    May 05, 2004
    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.

  • Anonymous
    May 06, 2004
    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?

  • Anonymous
    May 06, 2004
    The comment has been removed

  • Anonymous
    May 06, 2004
    http://blogs.msdn.com/junfeng/archive/2004/02/23/78139.aspx

  • Anonymous
    May 06, 2004
    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.

  • Anonymous
    May 06, 2004
    The comment has been removed

  • Anonymous
    May 07, 2004
    What constitutes "lots" of assemblies? 5? 10? 100?

  • Anonymous
    May 19, 2004
    I guess 10+ would mean lots of assemblies.

  • Anonymous
    July 15, 2008
    I've been hearing from several colleagues about how their Visual Studio solution files have many

  • Anonymous
    June 19, 2009
    PingBack from http://debtsolutionsnow.info/story.php?id=11700