Memory usage

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Platform: WinCE 4.2, C#

Newbie question:
Is there any difference in memory footprint between the 2 following
declarations:

public static Color FG_COLOR = Color.FromArgb(100,100,30);

public static Color FgColor
{
get {return Color.FromArgb(100,100,30);}
}

TIA,

Mark
 
Those two are different.

The first one creates a color and returns *it* everytime you ask.
The second creates a new color *every* time you ask

Go with the first one.

Cheers
Daniel
 
But color is a value type...
Woudn't the only difference be in a few lines of IL that stuff the RGB
values in the Color fields?
 
That is my understanding too. It basically creates a new Color object which
since it is a valuetype is simply assigning some variables (based on a bunch
of conditions, some shifting etc) so there is no heap allocations.

That doesn't change the recommendation to go with the first approach though
does it?

Cheers
Daniel
--
http://www.danielmoth.com/Blog/


Alex Feinman said:
But color is a value type...
Woudn't the only difference be in a few lines of IL that stuff the RGB
values in the Color fields?
 
No, of course it doesn't. I should have said that. I totally agree with you.
But, since the OP asked "Is there any difference in memory footprint between
the 2 following declarations", I thought my point would be relevant
 
Going back to what Daniel said earlier:

The first one creates a color and returns *it* everytime you ask.
The second creates a new color *every* time you ask

I have always assumed that only *one* instance of a static variable would be
created in any case(?) If that is the case the only difference would be when
the one instance is created(?)
 
I have always assumed that only *one* instance of a static variable would
be
created in any case(?)
Your statement is correct and that is what happens in your first scenario.
Like I said: The first one creates a color and returns *it* every time you
ask.

In the second case there is no static field (just a static method) so the
body of that method runs each time (creating/processing each time).
If that is the case the only difference would be when
the one instance is created(?)
It isn't the case (as explained above). The second approach creates
instances whenever it is called. However Alex makes a valid point that you
can interpret as: small perf hit (few IL instructions) in the second case
VERSUS holding the memory (under 10 bytes) throughout the lifetime of your
program in the first case [given that we are talking about a valuetype].

Now take a step back and look at what we are talking about here: we are
splitting hairs in terms of a design decision. My view is the same: go with
the one liner.

Cheers
Daniel
 
Please see my reply in your other post. In short, the "no heap allocations"
comment applies to the second approach where there are no static variables.

Cheers
Daniel
 
Just making sure I was not missing a trick... your point is definitely
relevant... :)

Cheers
Daniel
 
The first one creates a color and returns *it* every time you
In the second case there is no static field (just a static method) so the
body of that method runs each time (creating/processing each time)

So is it accurate to state that with the first declaration the Color
instance will be created and not Disposed until the process is stopped,
whereas with the second declaration there is the method code which is created
and not Disposed until the process ends(?)
 
So is it accurate to state that with the first declaration the Color
instance will be created and not Disposed until the process is stopped,
Until the appdomain is unloaded, yes.
whereas with the second declaration there is the method code which is
created
and not Disposed until the process ends(?)
No. Methods are not created. The IL is always there. It will compiled to
native code but that is susceptible to pitching. The code running in a
static method will run each time you call it. That is the penalty you pay.
To put it another way, static methods are no different to instance methods
apart from the way you call them.

Cheers
Daniel
 
Back
Top