Penguin

Differences between current version and previous revision of Profiling.

Other diffs: Previous Major Revision, Previous Author, or view the Annotated Edit History

Newer page: version 4 Last edited on Wednesday, September 15, 2004 1:53:33 pm by AristotlePagaltzis
Older page: version 3 Last edited on Thursday, September 2, 2004 12:09:21 am by StuartYeates Revert
@@ -1,5 +1,7 @@
-The collectoin of RunTime information for later use at CompileTime. 
+[Profiling] means monitoring code at RunTime to collect information about what it spends its time doing. The goal is to identify computationally intensive parts worthy of [Optimisation] -- either manually by a programmer tweaking the SourceCode, or automatically during CompileTime. 
  
-The profiling information is generally saved to disk , either as a summary (requires more RAM) or as a log (requires more disk) and then used to identify parts of the code which would most benefit from [Optimisation]s of various types . [HotSpotCompiler ]s do this all [AutoMagic]ally at runtime
+Automatic [Optimisation] generally yields much lower gains , but manual [Optimisation] is expensive . The two methods are therefor generally complementary; you will usually want to make initial [Optimisation ]s manually, yielding greater speedups before diminishing returns render further effort inefficient, and then squeeze out a little more performance yet by automatic means
  
-[GCC] uses the -pg argument to build excutables with profiling enabled and gprof(1) to display the resulting data. [Java ] can profile normally compiled classes, because the profiling infrastructure is built into the [JVM ], there is a standard interface to the profiling and debugging features and several user-level interfaces, including fancy GUI ones
+If a traditional [Compiler] is used, [Profiling] information is generally saved to disk, either as a summary (requires more [RAM]) or as a log (requires more diskspace), and then postprocessed for use by the [Compiler]. [GCC] uses the <tt> -pg</tt> argument to build BinaryExecutable~s instrumented with profiling code and gprof(1) to display the resulting data. The [JVM ] has profiling infrastructure already built into it, so normally compiled [Java ] classes can always be profiled. There is a standard interface to the profiling and debugging features and several user-level interfaces, including fancy [ GUI] applications.  
+  
+If a JustInTime [Compiler] is used, this work can also be done AutoMagic~ally at RunTime, in which case it is called a HotSpotCompiler. Many recent [JVM]s sport such a HotSpotCompiler