_In theory (am I wrong?):_
- Copy constructor:
1.) allocate memory
2.) individually initialize fields with 0/null
3.) individually initialize fields from initializers
4.) individually initialize fields from super/this constructors (can be many)
5.) individually copy values from original
6.) _optionally_ do some additional work
- Cloning:
1.) allocate memory
2.) copy all values(=memcopy/intrinsic) from original
3.) _optionally_ do some additional work via overriding clone()
_In practice:_
- Thanks for all your detailed answers!
I think most call sites that call clone() will have just one (maybe two)
receiver types
I was thinking about use cases in factories.
Especially cloning an already prepared master-object seems faster to me, than instantiating and
post-processing a virgin object.
In a former case, I had to use a given API, Charset#newDecoder(), to retrieve new decoder objects,
which share a big mapping table object (one for each distinct charset), which was expensive to load.
So the Charset class should hold a virgin decoder object by SoftReference to temporarily prevent the
mapping table from GCing, even if no decoder object was in use(=referenced from user code). As the
decoder object could be of different class type, a concrete (copy)constructor was not accessible.
So I had to decide between _expensive_ (copy)constructor _invocation via reflection_ or, as I think,
_cheap cloning_.
-Ulf
Am 31.01.2012 01:29, schrieb Vitaly Davidovich:
I agree that performance of clone vs copy ctor should be irrelevant in the
grand scheme of things -- I think this question is purely academic at this
point. I think most call sites that call clone() will have just one (maybe
two) receiver types, so the guard should predict every time in most cases,
and I'd imagine is a cheap check (a type check, which I believe is just a
few instructions). As for memcpy, I think some compilers generate better
code for it than others by substituting their own version instead of using
the library call, including using different instructions depending on
amount of data to copy and the machine architecture. Anyway, that's a
whole other topic. I think the general point is that calling clone() makes
a clearer indication of intent to the JVM, so in theory it should have more
room for optimization.
Cheers
On Mon, Jan 30, 2012 at 6:47 PM, Rémi Forax<fo...@univ-mlv.fr> wrote:
On 01/30/2012 10:17 PM, Vitaly Davidovich wrote:
I would also expect clone to run a bit faster than copy constructor, if
for
nothing else than clone not executing any constructor; this perf diff
would
probably be more noticeable in interpreter as compiler may inline
constructor. In addition, I'd also think that clone can basically be
equivalent to memcpy which should be faster.
It depends if the class if final or not.
If the class is not final the VM will have to add a guard before calling
Object.clone().
Object.clone() is intrinsified (lookup for 'intrinsics' in the source code)
so it will do a memcopy. A far as I remember, memcopy is slower that
copying
fields one by one if there is a few fields (otherwise it's faster).
Then you need a checkcast at the end and as far as I remember, the VM
doesn't remove it.
So as Tom said, if the class is final, using a copy constructor is usually
faster.
Anyway, this is too Hotspot specific and may change in the future,
moreover I've never seen a call clone() or to a copy constructor
being the performance bottleneck.
Stupid algorithms and bad choices of the data structures are far more
frequent.
Rémi
Sent from my phone
On Jan 30, 2012 4:08 PM, "Ulf Zibis"<ulf.zi...@gmx.de> wrote:
Am 30.01.2012 14:28, schrieb Tom Hawtin:
On 30/01/2012 13:16, Ulf Zibis wrote:
Isn't cloning faster than normal instantiation?
I can imagine, that behind the scenes cloning mainly only needs to
duplicate the binary footprint of an object.
I don't see a good reason why it should be (equally, I've not tried
benchmarking).
For the immediate fields of an object, (partial) bitwise copying "by
hand" should be of comparable performance to a bitwise clone. For
copying
the referenced objects, there is no benefit for the clone.
Is there anybody, who knows this exactly, e.g. in reference to Hotspot
runtime?
-Ulf
