Interesting.
A review from 2007 contains this:
{smartassembly} uses several different
techniques to bring down the memory
usage.
We asked the developers of
{smartassembly} for some of the
specifics, and they told us that by
default the CLR reserves a ton of
memory for .NET assemblies - whether
or not they request it. So
{smartassembly} intelligently detects
when the CPU is idle (or thereabout)
and increases or decreases the amount
of reserved memory for your assembly
according to its requirements -
"automated" GC in a sense, except that
memory may or may not have ever been
in use.
In that same vein, {smartassembly}
(with the benefit of literally having
access to your source code thanks to
the way .NET is designed) marks any
and all classes that don't have any
detectable "child" classes inheriting
from them as "sealed" thereby reducing
the amount of memory and CPU used by
the CLR during run-time to determine
what functions should be made
available to other classes and
libraries.
The same review has a "before/after" pair of screenshots showing an application going from 8M to 420K. This suggests to me that it's actually just reducing the working set of the application, not the real memory requirements. The same "optimisation" appears to occur if you minimise an app. It doesn't suddenly take up less memory. I don't believe the desktop .NET framework can really run with only 420K.
The automatic sealing feature is interesting - I can't see that it helps other than for lookup of virtual methods. I doubt that the impact is really significant, but of course I haven't benchmarked it.
So, nothing conclusive, but I doubt that it's doing anything that I'd particularly want.