> > TVector3 and TLorentzVector have been left unchanged since your mail > > and the discussion following it. These two classes were supposed to be in > > phase with the same classes in CLHEP. It is my understanding that the > CLHEP > > maintainers were against your proposal (from some private emails!). > > Yes, they were against it, although in the end they admitted that all their > arguments against it were specious and they were simply unwilling to change > their "perfect" class to allow it to be subclassed. (I claim and am willing > to demonstrate that any overhead is negligible in real performance terms). > > Concerning derivation from TNamed, I am also more than a little skeptical > about the notion that adding two strings is going to be a noticeable > performance problem in this age when memory of even low-end computers are > typically measured in 100's of MB. I think allowing more powerful and > understandable code to be written is far more important than saving a few > bytes here and there, but anyway. Let me stick my two cents in on performance. When you are writing an application, you should not worry too much about performance until you measure, profile, and quantify, find out where the bottlenecks are, and then fix those. I agree that in many cases fast computers are making issues that used to be important moot. However, when you build a library, this is completely different. Since you're building it (hopefully) for general use and re-use, you do not have any constraint on the application people will eventually put it to, and so you should make it as lean and mean as possible. In concrete terms for TVector3: Who are you to say that some user of ROOT will not need or want to work with groups of millions or tens of millions or even hundreds of millions of these objects? I can certainly conceive such applications. Then you are talking of overheads in the 100s of Mb or more range. When you're talking about overheads of 50% or 100%, it's 50% or 100% of what you want to use. Remember, along with the growth of computing power has also come the growth of demands on that power. Root should endeavor for as many people as possible to be able to use their classes without having to 'roll their own' for performance reasons. Writing clear and understandable code is of course desireable, but one of the virtues of C++ is that with good encapsulation of performance-sensitive areas, you can have your cake and eat it too. George Heintzelman gah@bnl.gov
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:35 MET