July 2004 - Posts

• The remarkable staying-power of of System.Assembly

  There was an interesting bug in NMock until recently (it's been fixed) which saw memory usage during unit test runs increase in relation to the total number of mock objects created during the run.  The culprit was .Net's inability to unload assemblies from a running AppDomain: each mock was being hosted in a brand new dynamic assembly - which never gets garbage collected - so you could easily end up with a few hundred assemblies languishing in the root domain, eating memory.  We fixed it by creating one assembly for all mock types, and by caching identical types for the duration of the test run. Today, another bug was raised against NMock, which involved calling GetManifestResourceNames() on all loaded assemblies.  Dynamic assembliles will throw NotSupportedException for this method (and for a couple of others), so if any code which relies on this call is used alongside NMock (in this case it was NVelocity), we break it. I looked at a couple of workarounds, including saving our mock assembly to disk and reloading it as a static assembly so it could play nicely, but noticed that AssemblyBuilder, which we use to generate the mock assembly, is never garbage collected either!  So, kids, be aware that if you generate assemblies at runtime, even just to save them to disk, your AssemblyBuilders will hang around for ever, holding you memory hostage and calling you "poo-breath" behind your back.  The solution, of course, is to do your code-gen in a separate AppDomain, which is pretty weak but at least you can throw it away when you're done. Does anyone have a good reason why assemblies cannot be garbage collected? Posted Jul 07 2004, 05:07 PM by jimski3000 with 3 comment(s)

• Build, old woman! Build like the wind!

  What's your build speed?  How long does it take between you clicking on the check-in button and the green (or red!) light appearing on the task bar telling you your build succeeded (or failed!).  In our case a finished build is announced by Homer shouting "woohoo!" or "D'oh!", and it takes around three minutes for the "express" build - just compilation and unit tests- and twenty minutes for the full build, which includes acceptance tests, MSI compilation and deployment.  That's for a 200,000 line application, which I suppose is medium-sized. Colleagues on different projects have remarked on this as being pretty quick, and have noted build speeds of 1 - 2 hours for similar sized applications.  The biggest overhead for them seems to be database activity, which we try to minimise by using mock objects and abstraction layers like Neo.  We also try to keep compile times as short as possible by aggresively deleting dead code, useless comments and using statements etc., and to keep unit tests small and well-targeted. So, it would be interesting to get a sense of how long other people sit around for waiting for a build, and what the biggest contributing factors to slow build speeds are.  Does your build take so long you only run it at night?  Do you find it unnecessary to build more than once a day (or even less frequently?).  Let me know. Posted Jul 07 2004, 04:24 PM by jimski3000 with 5 comment(s)