jeffb@grace.cs.washington.edu (Jeff Bowden) (05/31/89)
I'm writing a C++ program for which I really care about performance.
I'm using cfront 1.2. I recently profiled my program using gprof only to find
that 82% of my program execution time was being spent in a no-argument, EMPTY
CONSTRUCTOR. Needless to say, I was slightly annoyed. I find constructors
are very useful and I wish I could use them, but this is just too much.
The problem (which I found by examining the output of CC -F) is that
the empty constructor (which is defined in the class declaration, so it is
should to be inline) somehow gets incarnated and called as a normal function!
This wouldn't be so bad except that I declare many arrays of vectors
of this class and I generally use only 10% of the elements. (I have an empty
constructor because of the vectors; fascist cfront doesn't like it when you
declare vectors of things which haven't any no-argument constructor).
My current solution consists eliminating the constructors for this
class and using some overloaded `friend' functions in place of the constructors
(e.g. class foo { /*...*/ friend foo mkfoo(); /*...*/ }; ). This leads to a
vast improvement in performance, but it's damn ugly. Anyone have a better
suggestion/fix?????
--
"How well do you really know the back of your hand?"jss@hector.UUCP (Jerry Schwarz) (05/31/89)
In article <JEFFB.89May31002905@grace.cs.washington.edu> jeffb@grace.cs.washington.edu (Jeff Bowden) writes: > > The problem (which I found by examining the output of CC -F) is that >the empty constructor (which is defined in the class declaration, so it is >should to be inline) somehow gets incarnated and called as a normal function! > > This wouldn't be so bad except that I declare many arrays of vectors >of this class and I generally use only 10% of the elements. (I have an empty >constructor because of the vectors; fascist cfront doesn't like it when you >declare vectors of things which haven't any no-argument constructor). The reason C++ demands a no argument constructor is so that it can maintain what I call the "allocation guarantee". Namely every area of storage that it will call an X must be initialized by a constructor. In the case of something like X array[1000] this means that the X() constructor must be called 1000 times to "initialize" the areas that are holding an X. This is done by a function that is passed the constructor as an argument. This is why The X() constructor is being incarnated, and presumably it is also account for the profiling showing many calls to X(). > My current solution consists eliminating the constructors for this >class and using some overloaded `friend' functions in place of the constructors >(e.g. class foo { /*...*/ friend foo mkfoo(); /*...*/ }; ). This leads to a >vast improvement in performance, but it's damn ugly. Anyone have a better >suggestion/fix????? An alternative is to cause the allocation guarantee to be violated by a cast. Instead of allocating arrays directly create a class class arrayofX { public: arrayofX(int i) { a = (X*)new char[sizeof(X)*i] ; // by allocating as an array of char's // and then casting we avoid calls to // the X() constructor. } ~arrayofX() { delete a ; } X& operator[](int x) { return a[x] ; } private: X* a ; } ; This class can be used as follows arrayofX v(100) ; // v now behaves as if it had been declared // X v[100] ; X x ; v[5] = x ; // legal C++ is not "fascist". It does your require you to be explicit when you want to violate the typing of the language, but it allows you to do so. It does tend to require you to be more knowledgeable when you violate the typing than when you conform to the type system. IHHO this is a very reasonable attitude. Note that the above class will not work properly if X has virtual member functions. If you don't understand why, then you probably not use this technique. Jerry Schwarz AT&T Bell Labs, Murray Hill
jima@hplsla.HP.COM (Jim Adcock) (06/02/89)
> jeffb@grace.cs.washington.edu (Jeff Bowden) writes: > > > > The problem (which I found by examining the output of CC -F) is that > >the empty constructor (which is defined in the class declaration, so it is > >should to be inline) somehow gets incarnated and called as a normal function! > > > > This wouldn't be so bad except that I declare many arrays of vectors > >of this class and I generally use only 10% of the elements. (I have an empty > >constructor because of the vectors; fascist cfront doesn't like it when you > >declare vectors of things which haven't any no-argument constructor). > > The reason C++ demands a no argument constructor is so that it can > maintain what I call the "allocation guarantee". Namely every area > of storage that it will call an X must be initialized by a > constructor. In the case of something like > > X array[1000] > > this means that the X() constructor must be called 1000 times to > "initialize" the areas that are holding an X. This is done by a > function that is passed the constructor as an argument. This is why > The X() constructor is being incarnated, and presumably it is also > account for the profiling showing many calls to X(). One might hope for a compiler that inlines code for array initialization if a class's X() constructor is declared inline. I see nothing that requires a compiler to use a vector new function expecting a pointer to an X() constructor. For example, why couldn't a compiler pass a null function pointer to the vector new function, test in the vector new function whether or not to call that function, and then generate an inline for-loop with the inline X() constuctor to do the actual init? Good optimizing backend C "code generators" would be smart enough to void the loop if the X() constructor is null. Its ugly to have to come up with hack work-arounds for compiler deficiencies. Compilers need to do a much better job of respecting a user's request for inlining -- resolving inline verses non-inline compiler deficiencies presently takes me more time than all other aspects of C++ code writing! One might question how usable present compilers are for arrays of objects. I'm always having to find hack work-arounds. Is this what C++ is about ???
jima@hplsla.HP.COM (Jim Adcock) (06/06/89)
> For example, why couldn't a compiler pass a null > function pointer to the vector new function, test in the vector new function > whether or not to call that function, and then generate an inline for-loop > with the inline X() constuctor to do the actual init? Good optimizing > backend C "code generators" would be smart enough to void the loop if the > X() constructor is null. Alternately, one could at least hope that a compiler would recognize a null initialize, and just pass a null function pointer to the vector new function.