C# Performance question

[Bill O'Neill]

In our business frameworks we are creating objects off of the heap to
represent every small value such as a CustomerNumber. We will have thousands
of these small objects in an application at any one time. These objects are
very thin as most of the members have been declared static.



I proposed to my team that we use the flyweight design pattern to
significantly reduce the number of small objects we have in memory. This
will not be a simple modification so the rest of the team understandably
wants me to justify my decision. I don't know how; it's just based off of my
gut that the current practice is bad. I have reverse engineered the .NET
Framework and found that they are using the flyweight pattern to represent
column values within rows, which is effectively the same thing I am up
against. They must have had a reason to do this.



Am I wrong? Can .NET effectively handle tens of thousands of objects? If my
argument has merit, how can I prove it to the rest of the team? I tried
Googling this, but I did not have much luck.



BTW, the current implementation has other faults. For example, using mutable
reference objects to represent values has horrid side-effects. A lot of you
probably know this, so please don't let that distract you from the performan
question.



Thank you for your time.



Respectfully,

Bill O'Neill

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I proposed to my team that we use the flyweight design pattern to
significantly reduce the number of small objects we have in memory. This
will not be a simple modification so the rest of the team understandably
wants me to justify my decision. I don't know how; it's just based off of my
gut that the current practice is bad.

Am I wrong? Can .NET effectively handle tens of thousands of objects? If my
argument has merit, how can I prove it to the rest of the team? I tried
Googling this, but I did not have much luck.

I can not see a problem by having tens of thousands of objects.

Indeed I would expect many apps to have hundreds of thousands of
objects.

Note that I am not saying that usage of flyweight design pattern
in your case is a bad idea.

But tens of thousands of objects in itself does not justify it.

Arne

 

[Chris Nahr]

Am I wrong? Can .NET effectively handle tens of thousands of objects? If my
argument has merit, how can I prove it to the rest of the team? I tried
Googling this, but I did not have much luck.

Do you experience actual performance issues, such as intermittent
noticeable pauses when the garbage collection runs, or even disk
thrashing when the swap file is accessed? Is rapidly increasing
memory use restricting the lifetime of an application instance?

Or do you expect the flyweight implementation to reduce the memory
load so much that some computationally intensive algorithm might run
entirely within the CPU cache?

If neither of those is true you probably won't get much benefit from a
new implementation. .NET itself certainly doesn't have a problem with
tens of thousands of objects.

The CLR team has to pick very efficient algorithms because they're
creating a library that's used in applications of all kinds and sizes.
But in your case, if I understand you correctly, you're already
looking at the actual working set of a complete application. In this
case I would keep the alternative in mind but not bother to implement
it unless there's an actual performance issue.

By the way, you can use Microsoft's CLR Profiler to monitor your
application's use of managed memory:
http://msdn2.microsoft.com/en-us/netframework/aa569269.aspx

 

[Jon Skeet [C# MVP]]

In our business frameworks we are creating objects off of the heap to
represent every small value such as a CustomerNumber. We will have thousands
of these small objects in an application at any one time. These objects are
very thin as most of the members have been declared static.

I proposed to my team that we use the flyweight design pattern to
significantly reduce the number of small objects we have in memory. This
will not be a simple modification so the rest of the team understandably
wants me to justify my decision. I don't know how; it's just based off of my
gut that the current practice is bad. I have reverse engineered the .NET
Framework and found that they are using the flyweight pattern to represent
column values within rows, which is effectively the same thing I am up
against. They must have had a reason to do this.

Well, in some situations the flyweight pattern can be useful, but that
doesn't mean it always is. Thousands of objects can easily be handled
by .NET - particularly if they're short-lived, and thus never get out
of generation 0.

Am I wrong? Can .NET effectively handle tens of thousands of objects? If my
argument has merit, how can I prove it to the rest of the team? I tried
Googling this, but I did not have much luck.

BTW, the current implementation has other faults. For example, using mutable
reference objects to represent values has horrid side-effects. A lot of you
probably know this, so please don't let that distract you from the performan
question.

Mutable reference types have their downsides, but mutable value types
are worse, IMO. So long as you *know* a reference type is mutable, it's
often the right way to go, particularly if the value is likely to
change frequently.