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