Differences between version 4 and predecessor to the previous major change of Profiling.
Other diffs: Previous 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 | Revert |
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
.