2b5c606b   
   From: francis.glassborow@btinternet.com   
      
   On 01/04/2013 06:25, A. McKenney wrote:   
   > Francis Glassborow wrote:   
   >   
   >> Whilst I guess you cannot show the real code would you post:   
   >> 1) The test programs and methodology you used to come up with that   
   >>     claim.   
   >> 2) The general nature of the software being produced.   
   >   
   > I do not work for an academic institution, so I hope you will   
   > understand that I may feel the need to be circumspect with details,   
   > and that my employer might not see any benefit to my publishing   
   > anything.  Their only interest is in not needing to buy more hardware,   
   > network capacity, etc.   
      
   Yes, I realised that there could well be a proprietary concern but if   
   you are unable to even describe the nature of the software it becomes   
   impossible to ascertain the validity of your assertions about performance.   
      
   >   
   > I think I can describe the general methodology, since IMHO it's pretty   
   > obvious: Basically, we use recordings of actual data activity and   
   > replay them for testing.  We do profiling, make changes, and   
   > ultimately we have to prove that we've actually reduced CPU time and   
   > improved throughput by performance testing, again with recordings of   
   > actual production data activity.  Reducing the frequency of heap   
   > allocation/deallocation and the use of std::string (other than   
   > read-only access) tends to be the low-lying fruit.   
      
   Yes that demonstrates that what you did improved the performance, but   
   what it does not do is show that what you did was the most appropriate   
   way to improve performance.   
      
   For example, there is no fundamental problem with using std::string (and   
   the optimisation for short strings greatly reduces the costs). However a   
   lazy programming style can result in unnoticed excessive   
   construction/destruction of strings.   
      
   There are a number of techniques for reducing the cost of heap   
   allocation which include ensuring that the program has a sufficiently   
   large default heap.   
      
   There are many ways of reducing heap allocation/deallocation. I wonder   
   what mechanism you have in place to protect against stack overflow (a   
   very real risk if you are dealing with large arrays)   
      
      
   >   
   > I'm not interested in making any general claim about costs.  I simply   
   > wanted to indicate that the claim that allocation/deallocation costs   
   > can be ignored is not true in all applications.   
   >   
   >   
      
   I do not think that that was asserted. However you stated:   
      
      
   In fact, we use fixed-length arrays instead of std::vector if we know   
   the maximum length in advance, again, for performance reasons.[*] When   
   an extra 30% of performance can save you having to buy hardware that   
   costs a programmer's salary for a year, you care about all the stuff   
   that C++ gurus say doesn't matter any more.   
      
      
   Which sort of implies that using fixed length arrays was at least 30%   
   better than using a std::vector. Actually most experienced programmers   
   would use a C-style array if the length is known in advance and   
   performance is a critical issue. However that choice is not cost free   
   and does add to the requirements for maintenance (the programmer doing   
   that has to be familiar with C-style arrays and all the consequential   
   gotchas)   
      
   However all this is getting a long way from the origianl topic of this   
   thread.   
      
   Francis   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)