> That's not the point of what I keep trying to tell him.
 > A profiler would only gauge what a section of code does on
 > your machine
 > with your compiler.  And you end up low level tweaking your
 > code for
 > that situation, while those same tweaks cause slow downs for
 > everybody
 > else.  Using pointers vs. arrays is case in point.  Whether
 > it's
 > 'better' depends too much on the compiler and the CPU family.
 > That's what I've been trying to tell him.  Low level
 > tweakings of
 > the type he wants to do simply don't hold from one system &
 > compiler
 > to another.
I did not follow this discussion from the beginning.  A profiler is quite 
specific - for a specific compiler(and the executable it creates) and for a 
specific operating system for a specific CPU - as you have pointed out.
 
However, if you use the appropiate profiler - a different one for each set of 
compiler, CPU, and operating system then that profiler - if it is well 
designed and tested - will pin point where the most frequently used code is 
being executed in a program via statistical analysis.  
 
What is being optimized is the executable code that must run under a 
particular CPU, on a specific operating system - as produced by a specific 
compiler.  In my extesnive experience using professional profilers, profilers 
have demonstrated that they can, in general, do a much better job of pin 
pointing what source code is used most frequently.  
 
The very real problem with a profiler is that while they can pin point the 
most frequently executed code in a program they can not automatically improve 
the program.  Second, it takes a person who is a systems programmer and a 
operating system expert to improve the program as it operates under a 
particular operating system. A system programmer who is highly knowlegeable 
on the particular operating system involved.
 
The problem may not be in the programming code per se but in the way the code 
is utilizing the operating system.  If the program doesn't utilize perhaps 
more efficient parts of the operating system, or uses the operating system to 
misuse the peripherals then havoc results. 
 
This has been pretty much accepted for perhaps the last 20 or years or so.  
 
Low level tweaking - and I presume here you are speaking of using ass'y lang. 
code to replace compiler generated code MAY speed up certain parts of the 
compiler written code - that is not arguable.
What is agrueable is at what labor cost for a programmer to do the tweaking 
vs the savings in the total run time of a program in production - or saving 
in memory(that some othe task might be able to use).  Conclusion:  Low level 
tweaking is not worth it - 
---
---------------