Another memory question

  • Thread starter Thread starter John Baro
  • Start date Start date
J

John Baro

Going back a week or so I posted a question about whether it was better to
declare an object within a for loop so it gets declared each time or out of
the loop and then reuse the object each time.
Basic consensus was that it was better to declare it outside if it was going
to take a while to initialise.

Anyway..

More thoughts
If we declare it within the loop then each time it will create a new object
on the heap as compared to declaring it outside and setting it to new each
time which would theoretically reuse the object already on the heap.
Eventually to my thinking this will degrade performance as the GC will be
forced into action to clean up the heap.

On second thougths I dont think this is correct.
If we set any object to new it will create a new object on the heap
regardless of where the object was declared?
If we are setting an object to an existing object then it will simply point
to that object on the heap regardless of where it was declared?

Any thoughts??

Cheers

JB
Life is not a reality TV show.
 
Any thoughts??
Cheers

JB
Life is not a reality TV show.
Click to expand...

Barring arcane wizadry that I'm not aware of, every time you call new you
put an object on the heap.

You have your object on the heap, and a reference to it on the stack.
Whether you declare a reference to the object inside or outside your loop
actually has no effect on the resultant IL. You can check this out yourself
using ildasm.

Erik
 
Erik Frey said:
You have your object on the heap, and a reference to it on the stack.
Whether you declare a reference to the object inside or outside your loop
actually has no effect on the resultant IL. You can check this out yourself
using ildasm.
Click to expand...
Thought so.

Thanks Erik.
JB
 
John Baro said:
Going back a week or so I posted a question about whether it was better to
declare an object within a for loop so it gets declared each time or out of
the loop and then reuse the object each time.
Basic consensus was that it was better to declare it outside if it was going
to take a while to initialise.
Click to expand...

I don't believe that was the consensus. I believe the consensus was
that it would be better to declare it outside if (and only if) you
could reuse the same *object* (not just the same variable) for all
iterations of the loop - in other words, if you don't need to recreate
it for each iteration.

I believe that answers the rest of your question.
 
Erik Frey said:
Barring arcane wizadry that I'm not aware of, every time you call new you
put an object on the heap.
Click to expand...

There is *one* piece of arcane wizardry that I'm aware of (and am
slightly horrified by):

using System;

class Test
{
static void Main()
{
object x = new string(new char[]{});
object y = new string(new char[]{});

Console.WriteLine (x==y);
}
}

In other words, creating "new" empty strings actually doesn't (in some
cases, at least) - it reuses String.Empty.

Not that it's really relevant to the OP's question, but I thought you
might be interested...
 
In other words, creating "new" empty strings actually doesn't (in some
cases, at least) - it reuses String.Empty.

Not that it's really relevant to the OP's question, but I thought you
might be interested...
Click to expand...

Ah, hm. Interesting - I guess they use some selective overrides like
System.ValueType does.

I am going to whip this tidbit out at parties ;)

Thanks Jon.

Erik
 
Erik Frey said:
Ah, hm. Interesting - I guess they use some selective overrides like
System.ValueType does.
Click to expand...

What do you mean, exactly? I don't think it's really an override in the
normal sense (where ValueType actually overrides Equals, GetHashCode,
and ToString for instance). There's nothing *to* override in String. I
think it's just a grotty hack somewhere. Some time I should have a look
in the Rotor code and see if I can work out whether that does it too...
I am going to whip this tidbit out at parties ;)
Click to expand...

Now there's a sentence which could be taken out of context :)
 
What do you mean, exactly? I don't think it's really an override in the
normal sense (where ValueType actually overrides Equals, GetHashCode,
and ToString for instance). There's nothing *to* override in String. I
think it's just a grotty hack somewhere. Some time I should have a look
in the Rotor code and see if I can work out whether that does it too...
Click to expand...

I have NO idea about .NET internals, but I always assumed that
System.ValueType did something in its constructor (it has its own protected
constructor) that actually held some kind of specification (or IL) for how
to be allocated, and System.String might do something similar.

That might be a bit of a simplistic view, though.

Erik
 
Erik Frey said:
I have NO idea about .NET internals, but I always assumed that
System.ValueType did something in its constructor (it has its own protected
constructor) that actually held some kind of specification (or IL) for how
to be allocated, and System.String might do something similar.

That might be a bit of a simplistic view, though.
Click to expand...

I don't think it really works like that. Value types are odd - they're
sort of two types in one: one which is a reference type, which is the
boxed type - and that derives from ValueType - and one which is the
value type itself, and which you can't really get at except in normal
value type operation, if you see what I mean. It's all a bit weird
though, to be honest. Seems to work, mind you :)
 
Back
Top