MemberWiseClone speed and implementation?

  • Thread starter Thread starter Anders Borum
  • Start date Start date
A

Anders Borum

Hello!

I accidentally posted this as a reply to another posting. It is a seperate
posting - sorry :-)

I am programming a cloning service (which is essential to the framework),
and am currently using a custom implementation of the ICloneable interface.
With this in mind, I am wondering if I would be better off just using the
MemberWiseClone method of the inherited base object class.

Having measured the differences in speed, the MemberWiseClone implementation
was is approx. 25% slower than the custom implementation. We were debating
this at work and some suggested that I would benefit from future
improvements in the CLR implementation.

However, as this is a critical part of the framework, I believe a 25%
degradation would make the code suffer too much. Also, I could just run the
tests again when .NET 2.0 is released at a later time and change the cloning
service implementation if necessary.

The MemberWiseClone method forwards the call to an external method. I am
interested in the details of this implementation. Is the CLR using
reflection to clone the objects?

Thanks in advance.
 
Anders Borum said:
Hello!

I accidentally posted this as a reply to another posting. It is a seperate
posting - sorry :-)
Click to expand...

I was wondering why that was posted there, ;).
I am programming a cloning service (which is essential to the framework),
and am currently using a custom implementation of the ICloneable
interface.
With this in mind, I am wondering if I would be better off just using the
MemberWiseClone method of the inherited base object class.

Having measured the differences in speed, the MemberWiseClone
implementation
was is approx. 25% slower than the custom implementation. We were debating
this at work and some suggested that I would benefit from future
improvements in the CLR implementation.

However, as this is a critical part of the framework, I believe a 25%
degradation would make the code suffer too much. Also, I could just run
the
tests again when .NET 2.0 is released at a later time and change the
cloning
service implementation if necessary.

The MemberWiseClone method forwards the call to an external method. I am
interested in the details of this implementation. Is the CLR using
reflection to clone the objects?
Click to expand...

I do not believe so, no. If memory serves, MemberwiseClone is effectivly a
memcopy, copying the whole object into a new location and doing whatever bit
twiddling needs to be done to establish a new object. However, by all tests
I've run it looks like custom cloning is even faster on empty objects. It is
a curiosity to say the least.

Some crucial differences to consider:

A manual clone involves a new object creation and thus a constructor
invocation, MemberwiseClone does not invoke a constructor, so if your
constructor does things you want or don't want to happen, you'll need to
make yoru choices based on that.

MemberwiseClone is a bit more version proof. Much like copy constructors, an
IClonable::Clone method is hard to implement virtually, you end up with an
effective hiearchy of virtual Clone(T) implemetnations with every subsequent
class implementing ICloneable::Clone() anew so that the proper class is
created and passed down, any other mechanism will generate a different type.
By using MemberwiseClone you can simply implement the virtual Clone(T)
method and provide a single implementation of IClonable::Clone() which calls
MemberwiseClone and passes the returned object down the Clone hiearchy(or
have it passed up, as you will).

MemberwiseClone is shallow, so for deep copy semantics you'll have to use
some form of custom cloning code.
 
Hello Daniel
I was wondering why that was posted there, ;).
Click to expand...

Yes, I can't even find that posting now and sat waiting for it to appear in
the topics list. It's friday, what can I say .. sat till 02:30 AM in the
morning coding as usual (while the family was sleeping =o)
I do not believe so, no. If memory serves, MemberwiseClone is effectivly a
memcopy, copying the whole object into a new location and doing whatever bit
twiddling needs to be done to establish a new object. However, by all tests
I've run it looks like custom cloning is even faster on empty objects. It is
a curiosity to say the least.
Click to expand...

Not sure I put the numbers correct in the original posting, but these are
the results from the performance test. I'm initiating a cloning of some 12,3
mio. objects just to push some numbers.

Initiating cloning of 12800000 objects ..
Calculating custom cloning .. 2,921875 seconds.
Calculating MemberWiseClone .. 4,234375 seconds.

This is the release code with default (release) optimizations from VS .NET
2003 on a Dual 1.2Ghz AthlonMP workstation. The VS .NET console project is
available here:

http://adsl.sphereworks.dk/ClonePerformanceConsole.rar
Some crucial differences to consider:

A manual clone involves a new object creation and thus a constructor
invocation, MemberwiseClone does not invoke a constructor, so if your
constructor does things you want or don't want to happen, you'll need to
make yoru choices based on that.
Click to expand...

Didn't know that about MemberWiseClone, but I am not dependend on any
constructor calls (the models are, so to speak, just models and are served
from a set of service factories that sets state).
MemberwiseClone is a bit more version proof. Much like copy constructors, an
IClonable::Clone method is hard to implement virtually
Click to expand...

Yes, that's true. However, the current architecture contains sealed models
(where the cloning is imlemented currently), so I am in control of the
cloning process. But I do agree that in the case where you'd offer
inheritance from your models, it's a safer path using MemberWiseClone.

My problem is that tests showed MemberWiseClone to be quite slow compared to
the custom implementation. I am, again, not sure if the test I made are 100%
perfect. This is also why I'm asking for your oppinion.
By using MemberwiseClone you can simply implement the virtual Clone(T)
method and provide a single implementation of IClonable::Clone() which calls
MemberwiseClone and passes the returned object down the Clone hiearchy(or
have it passed up, as you will).
Click to expand...

That's the technique I'm using in the performance test.
MemberwiseClone is shallow, so for deep copy semantics you'll have to use
some form of custom cloning code.
Click to expand...

Yes, I'm aware of the differences. However, all my models use valuetypes
internally and those are the values I'm interested in cloning. This is also
the reason for considering MemberWiseClone at all (if a deep copy was
required, I'd probably stick with ICloneable as per .NET recommendations).
 
Didn't know that about MemberWiseClone, but I am not dependend on any
constructor calls (the models are, so to speak, just models and are served
from a set of service factories that sets state).


Yes, that's true. However, the current architecture contains sealed models
(where the cloning is imlemented currently), so I am in control of the
cloning process. But I do agree that in the case where you'd offer
inheritance from your models, it's a safer path using MemberWiseClone.

My problem is that tests showed MemberWiseClone to be quite slow compared
to
the custom implementation. I am, again, not sure if the test I made are
100%
perfect. This is also why I'm asking for your oppinion.
Click to expand...

Ahh, I'm sorry if I misphrased myself originally, but my tests support
yours, I can't get MemberwiseClone to outperform ICloneable.Clone, although
I'm showing about a considerable difference. Since you make it clear later
on that there is nothing else requiring you to use MemberwiseClone, I would
recommend using ICloneable::Clone until such a point where MemberwiseClone
is required.

FWIW, preliminary tests on the 2.0 framework were no better.

My results for 1 million clone iterations over an emtpy object:

MemberwiseClone Time: 00:00:00.1406250
Clone Time: 00:00:00.0156250
 
Hello!
Ahh, I'm sorry if I misphrased myself originally, but my tests support
yours, I can't get MemberwiseClone to outperform ICloneable.Clone, although
I'm showing about a considerable difference.
Click to expand...

The test I've performed indicates that the larger number of fields to be
cloned, the larger difference.
Since you make it clear later
on that there is nothing else requiring you to use MemberwiseClone, I would
recommend using ICloneable::Clone until such a point where MemberwiseClone
is required.
Click to expand...

I came to the same conclusion, but I thought I'd better be safe than sorry.
FWIW, preliminary tests on the 2.0 framework were no better.

My results for 1 million clone iterations over an emtpy object:

MemberwiseClone Time: 00:00:00.1406250
Clone Time: 00:00:00.0156250
Click to expand...

That's a considerable difference. Looking at these numbers, I am quite sure
I won't be using the MemberWiseClone approach. The cloning service is
crucial to the performance of the application so I need to squeze as much
performance from the CLR as possible.

If possible, could I get a copy of your test solution?

Thanks for helping out btw!
 
Anders Borum said:
Hello!


The test I've performed indicates that the larger number of fields to be
cloned, the larger difference.


I came to the same conclusion, but I thought I'd better be safe than
sorry.


That's a considerable difference. Looking at these numbers, I am quite
sure
I won't be using the MemberWiseClone approach. The cloning service is
crucial to the performance of the application so I need to squeze as much
performance from the CLR as possible.

If possible, could I get a copy of your test solution?
Click to expand...

Sure, this is just a basic "take a shot and see waht happens thing", I
didn't put much effort into it:

using System;

public class Test : ICloneable
{
public Test()
{
//Console.WriteLine("Constructor!"); //uncomment this if you want to test
constructor calls.
}

public object Clone()
{
return new Test();
}
public static void Main(string[] args)
{
Test a = new Test();
a.MemberwiseClone(); //warming the paths a little
a.Clone();

DateTime start, finish;
start = DateTime.Now;
for (int i = 0; i < 1000000; i++)
a.MemberwiseClone();

finish = DateTime.Now;
Console.WriteLine("MemberwiseClone Time: " + (finish - start));
start = DateTime.Now;
for (int i = 0; i < 1000000; i++)
a.Clone();

finish = DateTime.Now;
Console.WriteLine("Clone Time: " + (finish - start));

}
}

It lacks subtlety, but the difference was significant enough I decided not
to go for the slightly more complicated tick count approach or the
considerably more accurat high performance timer approach. I'm lazy that
way, ;).

One interesting possibility is that Clone may well be inlinable(I can't
remember if interface membership excludes inlining off hand), while
MemberwiseClone probably is not. That could be a significant issue across a
huge number of execuations on its own.

My tests were run on a dual 2.2 ghz Xeon, btw.
 
Hello!
It lacks subtlety, but the difference was significant enough I decided not
to go for the slightly more complicated tick count approach or the
considerably more accurat high performance timer approach. I'm lazy that
way, ;).
Click to expand...

Yes, I'm that way too .. the initial pointers told me I didn't need that
kind of precision to make up my mind. I would, however, argue that my
provided solution is more tidy that your example ;-)

Session ended from Nostromo.
Ripley signing out ..
 
Back
Top