Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!usc!zaphod.mps.ohio-state.edu!rpi!batcomputer!munnari.oz.au!comp.vuw.ac.nz!actrix!Bruce.Hoult
From: Bruce.Hoult@bbs.actrix.gen.nz
Newsgroups: comp.lang.c++
Subject: Re: why is this program slow?
Message-ID: <1991Jan11.012334.3629@actrix.gen.nz>
Date: 11 Jan 91 01:23:34 GMT
References: <1991Jan9.002244.23398@news.cs.indiana.edu>
Sender: Bruce.Hoult@actrix.gen.nz (Bruce Hoult)
Organization: Actrix Information Exchange, Wellington, New Zealand
Lines: 26
Comment-To: shirley@iuvax.cs.indiana.edu

Peter Shirley writes:
>I have a C++ program that takes about 170% as long as a similar C program.
>I've run it on a vax and a sun with and without big-O.
>I've inlined everything I can, and I don't understand the slowdown.
>Could someone enlighten me?  (yes, I looked at the C code generated
>by CC, and am too dumb to understand it).
 
 
I get the same thing on my Mac IIcx: the C program takes 31 seconds, and
the C++ one takes 54.
 
The problem is that the compiler isn't all that smart and is (on my
system, and probably on yours) copying the result of operator+ twice
on the way to its final destination -- the first time using a bitwise
copy (the default copy constructor), and the second time using the
operator= that you defined.
 
One way to work around the problem is to define an operator+=.  This will
drop the execution time down to virtually the same as for the C program.

Another way is to put the output of CFront through a smarter C compiler. I
suspect that GCC would do a rather better job of optomising the mess that
CFront leaves behind.
-- 
Bruce.Hoult@bbs.actrix.gen.nz   Twisted pair: +64 4 772 116
BIX: brucehoult                 Last Resort:  PO Box 4145 Wellington, NZ