 | |
Clone vs New?
Dotnet Framework (Performance) microsoft.public.dotnet.framework.performance
 |
| | Thread Tools | Search this Thread | Display Modes |
#1
 
| |||
| |||
|
Clone vs New? -
10-02-2007
, 01:07 AM
#2
| |||
| |||
|
|
It seems that in some cases its quicker to clone an existing object vs creating a new object. I have not done exstensive perf test but have found cases where it helps. Anyone have any thoughts on this? Why would this be true? Is it always true? if not then why not? Thanks, Schneider |
Cloning and copying are two different things, but most of the time they are
implemented in the same way (object!=object.clone()).
For example, the string.clone() returns a reference to the same string. As
strings are immutable, this is quite correct.
The stack collection instead does a deep copy, by creating a new object and
then copying the array inside it,
so there is no performance difference here with creating new or cloning.
The generic collections do not even have a clone() method.
Most of the System.Drawing objects implement Clone() as creating a copy of
the instance, so no difference here either.
#3
| |||
| |||
|
|
It seems that in some cases its quicker to clone an existing object vs creating a new object. I have not done exstensive perf test but have found cases where it helps. Anyone have any thoughts on this? Why would this be true? Is it always true? if not then why not? Thanks, Schneider |
#4
| |||
| |||
|
|
Laura's answer is dead on - Cloning & Creating a new Instance are two very different things with very different use cases. In a number of projects I work on, we built the cornerstone of our algorithms on the Prototype Pattern, which is a Clone() based implementation. Cloning is great, and has a wide variety of use cases. In most cases though, cloning is going to be quite a bit slower than creating a new instance. The code for cloning is often going to look like: public object Clone() { Foo o = new Foo(); o.ListOfNames = this.ListOfNames; o.Owner = this.Owner; return o; } This is clearly slower than just creating a new instance of Foo, as more stuff is going on. As Cloning gets more complex (as it always does) it's not uncommon to use Xml or binary Serialization, or even (and this is bad!) do a database dip. Note: The above code has a subtle bug that often bites people. Both copies (old and new) point to the same instance of ListOfNames & Owner. In the case of the string (Owner) this may not be a problem, as strings are immutable, but for many other things (Lists, Dictionaries, Datasets, etc), it's a catastrophic and subtle bug. If someone goes "old.ListOfNames.Clear()" both instances are affected. Anyone know why Microsoft never made a Generic IClonable? This always seemed silly, as IClonable<T> would eliminate the cast that always happens on clone. I usually end up with two methods: public object Clone(){} public MyType CloneAsMyType() { return (MyType) Clone());} -- Chris Mullins "schneider" <eschneider (AT) ooooooooo (DOT) com> wrote in message news:emvRHGLBIHA.3716 (AT) TK2MSFTNGP03 (DOT) phx.gbl... It seems that in some cases its quicker to clone an existing object vs creating a new object. I have not done exstensive perf test but have found cases where it helps. Anyone have any thoughts on this? Why would this be true? Is it always true? if not then why not? Thanks, Schneider |
#5
| |||
| |||
|
|
I understand your points. assuming I wanted the same object with no state, would it be faster to clone vs create? I guess i'm wondering if it does any optimization because it knows more about what the end goal is? Like it has a good idea of memory required, security. "Chris Mullins [MVP - C#]" <cmullins (AT) yahoo (DOT) com> wrote in message news:OtKtfrRBIHA.3916 (AT) TK2MSFTNGP02 (DOT) phx.gbl... Laura's answer is dead on - Cloning & Creating a new Instance are two very different things with very different use cases. In a number of projects I work on, we built the cornerstone of our algorithms on the Prototype Pattern, which is a Clone() based implementation. Cloning is great, and has a wide variety of use cases. In most cases though, cloning is going to be quite a bit slower than creating a new instance. The code for cloning is often going to look like: public object Clone() { Foo o = new Foo(); o.ListOfNames = this.ListOfNames; o.Owner = this.Owner; return o; } This is clearly slower than just creating a new instance of Foo, as more stuff is going on. As Cloning gets more complex (as it always does) it's not uncommon to use Xml or binary Serialization, or even (and this is bad!) do a database dip. Note: The above code has a subtle bug that often bites people. Both copies (old and new) point to the same instance of ListOfNames & Owner. In the case of the string (Owner) this may not be a problem, as strings are immutable, but for many other things (Lists, Dictionaries, Datasets, etc), it's a catastrophic and subtle bug. If someone goes "old.ListOfNames.Clear()" both instances are affected. Anyone know why Microsoft never made a Generic IClonable? This always seemed silly, as IClonable<T> would eliminate the cast that always happens on clone. I usually end up with two methods: public object Clone(){} public MyType CloneAsMyType() { return (MyType) Clone());} -- Chris Mullins "schneider" <eschneider (AT) ooooooooo (DOT) com> wrote in message news:emvRHGLBIHA.3716 (AT) TK2MSFTNGP03 (DOT) phx.gbl... It seems that in some cases its quicker to clone an existing object vs creating a new object. I have not done exstensive perf test but have found cases where it helps. Anyone have any thoughts on this? Why would this be true? Is it always true? if not then why not? Thanks, Schneider |
#6
| |||
| |||
|
|
If you want the same object with no state, I would go with "new" every time. Often the right high level option is to use a Factory Pattern, which abstracts this from your code: MyObject o = MyObjectFactory.CreateMyObject(); That way you can implement the creation logic any which way. -- Chris Mullins "schneider" <eschneider.news.ms (AT) starkinvestments (DOT) com> wrote in message news:eZt$99RBIHA.324 (AT) TK2MSFTNGP04 (DOT) phx.gbl... I understand your points. assuming I wanted the same object with no state, would it be faster to clone vs create? I guess i'm wondering if it does any optimization because it knows more about what the end goal is? Like it has a good idea of memory required, security. "Chris Mullins [MVP - C#]" <cmullins (AT) yahoo (DOT) com> wrote in message news:OtKtfrRBIHA.3916 (AT) TK2MSFTNGP02 (DOT) phx.gbl... Laura's answer is dead on - Cloning & Creating a new Instance are two very different things with very different use cases. In a number of projects I work on, we built the cornerstone of our algorithms on the Prototype Pattern, which is a Clone() based implementation. Cloning is great, and has a wide variety of use cases. In most cases though, cloning is going to be quite a bit slower than creating a new instance. The code for cloning is often going to look like: public object Clone() { Foo o = new Foo(); o.ListOfNames = this.ListOfNames; o.Owner = this.Owner; return o; } This is clearly slower than just creating a new instance of Foo, as more stuff is going on. As Cloning gets more complex (as it always does) it's not uncommon to use Xml or binary Serialization, or even (and this is bad!) do a database dip. Note: The above code has a subtle bug that often bites people. Both copies (old and new) point to the same instance of ListOfNames & Owner. In the case of the string (Owner) this may not be a problem, as strings are immutable, but for many other things (Lists, Dictionaries, Datasets, etc), it's a catastrophic and subtle bug. If someone goes "old.ListOfNames.Clear()" both instances are affected. Anyone know why Microsoft never made a Generic IClonable? This always seemed silly, as IClonable<T> would eliminate the cast that always happens on clone. I usually end up with two methods: public object Clone(){} public MyType CloneAsMyType() { return (MyType) Clone());} -- Chris Mullins "schneider" <eschneider (AT) ooooooooo (DOT) com> wrote in message news:emvRHGLBIHA.3716 (AT) TK2MSFTNGP03 (DOT) phx.gbl... It seems that in some cases its quicker to clone an existing object vs creating a new object. I have not done exstensive perf test but have found cases where it helps. Anyone have any thoughts on this? Why would this be true? Is it always true? if not then why not? Thanks, Schneider |
#7
| |||
| |||
|
|
Laura's answer is dead on - Cloning & Creating a new Instance are two very different things with very different use cases. In a number of projects I work on, we built the cornerstone of our algorithms on the Prototype Pattern, which is a Clone() based implementation. Cloning is great, and has a wide variety of use cases. In most cases though, cloning is going to be quite a bit slower than creating a new instance. The code for cloning is often going to look like: public object Clone() { Foo o = new Foo(); o.ListOfNames = this.ListOfNames; o.Owner = this.Owner; return o; } This is clearly slower than just creating a new instance of Foo, as more stuff is going on. As Cloning gets more complex (as it always does) it's not uncommon to use Xml or binary Serialization, or even (and this is bad!) do a database dip. Note: The above code has a subtle bug that often bites people. Both copies (old and new) point to the same instance of ListOfNames & Owner. In the case of the string (Owner) this may not be a problem, as strings are immutable, but for many other things (Lists, Dictionaries, Datasets, etc), it's a catastrophic and subtle bug. If someone goes "old.ListOfNames.Clear()" both instances are affected. Anyone know why Microsoft never made a Generic IClonable? This always seemed silly, as IClonable<T> would eliminate the cast that always happens on clone. I usually end up with two methods: public object Clone(){} public MyType CloneAsMyType() { return (MyType) Clone());} -- Chris Mullins "schneider" <eschneider (AT) ooooooooo (DOT) com> wrote in message news:emvRHGLBIHA.3716 (AT) TK2MSFTNGP03 (DOT) phx.gbl... It seems that in some cases its quicker to clone an existing object vs creating a new object. I have not done exstensive perf test but have found cases where it helps. Anyone have any thoughts on this? Why would this be true? Is it always true? if not then why not? Thanks, Schneider |
#8
| |||
| |||
|
|
I guess the problem with generics cloning comes from the possibility that a T> might not be cloneable. Another point is the semantic mismatch of ICloneable interface.. does it mean shallow/deep? You can read a very good discussion here: http://blogs.msdn.com/brada/archive/...03/125427.aspx More interesting cloning subtleties: http://blogs.msdn.com/abhinaba/archi...19/578518.aspx "Chris Mullins [MVP - C#]" <cmullins (AT) yahoo (DOT) com> ha scritto nel messaggio news:OtKtfrRBIHA.3916 (AT) TK2MSFTNGP02 (DOT) phx.gbl... Laura's answer is dead on - Cloning & Creating a new Instance are two very different things with very different use cases. In a number of projects I work on, we built the cornerstone of our algorithms on the Prototype Pattern, which is a Clone() based implementation. Cloning is great, and has a wide variety of use cases. In most cases though, cloning is going to be quite a bit slower than creating a new instance. The code for cloning is often going to look like: public object Clone() { Foo o = new Foo(); o.ListOfNames = this.ListOfNames; o.Owner = this.Owner; return o; } This is clearly slower than just creating a new instance of Foo, as more stuff is going on. As Cloning gets more complex (as it always does) it's not uncommon to use Xml or binary Serialization, or even (and this is bad!) do a database dip. Note: The above code has a subtle bug that often bites people. Both copies (old and new) point to the same instance of ListOfNames & Owner. In the case of the string (Owner) this may not be a problem, as strings are immutable, but for many other things (Lists, Dictionaries, Datasets, etc), it's a catastrophic and subtle bug. If someone goes "old.ListOfNames.Clear()" both instances are affected. Anyone know why Microsoft never made a Generic IClonable? This always seemed silly, as IClonable<T> would eliminate the cast that always happens on clone. I usually end up with two methods: public object Clone(){} public MyType CloneAsMyType() { return (MyType) Clone());} -- Chris Mullins "schneider" <eschneider (AT) ooooooooo (DOT) com> wrote in message news:emvRHGLBIHA.3716 (AT) TK2MSFTNGP03 (DOT) phx.gbl... It seems that in some cases its quicker to clone an existing object vs creating a new object. I have not done exstensive perf test but have found cases where it helps. Anyone have any thoughts on this? Why would this be true? Is it always true? if not then why not? Thanks, Schneider |
#9
| |||
| |||
|
|
It seems that in some cases its quicker to clone an existing object vs creating a new object. I have not done exstensive perf test but have found cases where it helps. |
depend on what the method does.
If your object implements clone like this:
public object() Clone
{
return this;
}
It will be faster than creating a new instance, because it is not
actually doing so.
But there is other thing not mentioned here that might be interesting
to note.
This is a common implementation of Clone():
public object() Clone
{
return MemberwiseClone();
}
This will return a new instance of the object with all the fields
copied (shallow copy) from the original, so in many ways is similar to
calling new and copying the fields.
Now the interesting thing (and that might be cause of many subtle bugs)
is that MemberwiseClone will *not* call the constructor method on the
new object.
If the constructor of your object is something like this:
public MyObject()
{
SomeVerySlowThings();
}
Then cloning will be faster than creating a new instance, since
SomeVerySlowThings() will not be called when creating the copy.
Again, note that this behavior might not be what you want, so you need
to take a lot of care when using MemberwiseClone(), and make sure any
important logic that should be done for each object is called in the
clone method besides the constructor. You will probably need to call
VerySlowThings in Clone() too.
As a way to clarify all of this, here is a simple console app:
using System;
using System.Collections.Generic;
using System.Text;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Stating test");
MyObject o = new MyObject();
Console.WriteLine("Object 1 has been created");
MyObject o2 = o.Clone() as MyObject;
Console.WriteLine("Object 1 has been cloned");
}
}
class MyObject : ICloneable
{
public MyObject()
{
Console.WriteLine("Entering constructor");
}
#region ICloneable Members
public object Clone()
{
return MemberwiseClone();
}
#endregion
}
}
If you look at the result, you will see that the "Entering constructor"
is printed only when creating the object, but not when cloning it.
If whatever goes in the constructor is slow, clone will be faster.
Regards,
Adrian.
|
« Previous Thread
|
Next Thread »
| Thread Tools | Search this Thread |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.4
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.