ruby-prof 0.8.1-x86-mingw32 → 0.11.0.rc1-x86-mingw32

data/CHANGES

@@ -1,3 +1,79 @@
+0.11.0.rc1 (2012-03-24)
+======================
+* On Windows, use QueryPerformanceCounter and QueryPerformanceFrequency to measure CPU time instead
+  of rdtsc.  This change is based on Microsoft's recommendation (Charlie Savage).
+* On Windows use GetProcessTimes to return real PROCESS_TIME times instead of wall times (Charlie Savage).
+* Big internal refactoring of C code to make RubyProf easier to understand and extend (Charlie Savage).
+* Profile results are now returned as instances of a new class RubyProf::Profile.  The old api 
+  is supported via a compatability layer that at some point will be deprecated.  (Charlie Savage).
+* Split out tests for cpu_time, process_time and wall_time into separate files (Charlie Savage).
+* Dropped support for Ruby 1.8.4 and 1.8.6 - does anybody still use these? (Charlie Savage).
+* Added support for sorting results by total, self, wait and child times (Jan Suchal)
+* Added tests for sorting behaviour & removed options from constructor to print method (Jan Suchal)
+* Fix line number tests due to changes at top of file (Charlie Savage).
+* Add encoding statement to top of all files for Ruby 1.9.x compatability (Charlie Savage).
+* Add def file for VC to avoid the whole declspec annoyance (Charlie Savage).
+* Update test suite to ensure current working directory is correct (Charlie Savage).
+* Modernize gem file and remove various custom/home grown solutions that aren't needed anymore (Charlie Savage).
+* Remove custom mingw build scripts, use rake compiler instead  (Charlie Savage).
+* Fixes for compiling with VC 2010 (Charlie Savage).
+
+0.10.8 (2011-07-06)
+======================
+* 1.9.3 super class (Roger Pack)
+
+0.10.7 (2011-05-09)
+======================
+* Fix a bug with REE's GC stats. Issue #53 [thanks graaff]
+
+0.10.6 (2011-04-29)
+======================
+* Slightly more normalized url for linux/windows links to files.
+
+0.10.5 (2011-04-20)
+=======================
+* 1.8.6 compat for -v command (bug fix)
+
+0.10.4 (2011-04-20)
+=======================
+* Faster load time for ruby-prof itself.
+
+0.10.3
+=======================
+* Can cleanly load before rubygems now.
+
+0.10.2
+=======================
+* Fix for 1.9.2, os x for latest commits (thanks skaes!)
+
+0.10.1
+=======================
+* Fix bug in linux wall time, also load with only relative paths so that you can use it to benchmark rubygems startup overhead,
+  itself.
+
+0.10.0
+=======================
+* Some rdoc changes, for linux wall time attempt to use higher granularity (thanks to all the contributors for this round!)
+
+0.9.2
+=======================
+* Make graphviz work on 1.8.6
+* Roll back some 1.9.2 optimizations until I can figure out what caused them.
+
+0.9.1
+=======================
+* Add a graphviz output
+
+0.9.0
+=======================
+* measurements for recursive methods are now correct
+* gave up on splitting up recursive methods according to call depth
+* made it possible to eliminate methods from profiling results
+* new printer for call stack visualization
+* new printer to print several profiles in one run
+* HTML profiles contain Textmate links so you can jump to the source code easily
+* producing an event log is now a runtime option
+
 0.7.10 (2009-01-22)
 =======================
 * fix SEGFAULT in 1.9
@@ -55,29 +131,29 @@
 
 Features
 --------
-* Added two new methods - RubyProf.resume and RubyProf.pause. 
+* Added two new methods - RubyProf.resume and RubyProf.pause.
   RubyProf.resume takes an optional block, which ensures that
   RubyProf.pause is called.  For example:
-  
+
   10.times do |i|
     RubyProf.resume do
       # Some long process
     end
   end
-  
+
   result = RubyProf.stop
 
 * Added support for profiling tests that use Ruby's built-in
-  unit test framework (ie, test derived from 
+  unit test framework (ie, test derived from
   Test::Unit::TestCase).  To enable profiling simply add
   the following line of code to your test class:
-  
+
     include RubyProf::Test
-    
-  By default, profiling results are written to the current 
+
+  By default, profiling results are written to the current
   processes working directory.  To change this, or other
   profiling options, simply modify the PROFILE_OPTIONS hash
-  table as needed.        
+  table as needed.
 
 * Used the new support for profiling test cases to revamp
   the way that Rails profiling works.  For more information
@@ -93,8 +169,8 @@ Features
 
 * Add support for Lloyd Hilaiel's Ruby patch for measuring total heap size.
    See http://lloydforge.org/projects/ruby. (Jeremy Kemper).
-  
-  
+
+
 Fixes
 -------
 * RubyProf.profile no longer crashes if an exception is
@@ -102,7 +178,7 @@ Fixes
 
 * Measure memory in fractional kilobytes rather than rounding down (Jeremy Kemper)
 
-  
+
 0.6.0 (2008-02-03)
 ========================
 
@@ -122,7 +198,7 @@ Fixes
   fixes for min_time support, ability to specify templates using
   strings or filenames, and table layout fixes (Makoto Kuwata)
 * Fixes to scaling factor for calltrees so that precision is not lost
-  due to the conversion to doubles (Sylvain Joyeux) 
+  due to the conversion to doubles (Sylvain Joyeux)
 * Changed constant ALLOCATED_OBJECTS to ALLOCATIONS in the C code to
   match the Ruby code (Sylvain Joyeux)
 * Added support for calltree printer to ruby-prof binary script (Sylvain Joyeux)
@@ -132,7 +208,7 @@ Fixes
 * Fix ruby-prof to work with the latest version of GEMS (Alexander Dymo)
 * Always define MEASURE_CPU_TIME and MEASURE_ALLOCATIONS in Ruby code, but
   set their values to nil if the functionality is not available.
-   
+
 
 0.5.2 (2007-07-19)
 ========================

data/LICENSE

@@ -1,15 +1,16 @@
-Copyright (C) 2005  Shugo Maeda <shugo@ruby-lang.org>
+Copyright (C) 2005 - 20011 Shugo Maeda <shugo@ruby-lang.org> and Charlie Savage <cfis@savagexi.com>
 All rights reserved.
- *
+
 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions
 are met:
+
 1. Redistributions of source code must retain the above copyright
    notice, this list of conditions and the following disclaimer.
 2. Redistributions in binary form must reproduce the above copyright
    notice, this list of conditions and the following disclaimer in the
    documentation and/or other materials provided with the distribution.
- *
+
 THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
 ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE

data/{README → README.rdoc}

@@ -5,89 +5,82 @@
 ruby-prof is a fast code profiler for Ruby.  Its features include:
 
 * Speed - it is a C extension and therefore many times faster than the standard Ruby profiler.
-* Modes - Ruby prof can measure a number of different parameters, including
-          call times, memory usage and object allocations. 
+* Modes - Ruby prof can measure a number of different parameters, including call times, memory usage and object allocations.
 * Reports - can generate text and cross-referenced html reports
   - Flat Profiles - similar to the reports generated by the standard Ruby profiler
   - Graph profiles - similar to GProf, these show how long a method runs, which methods call it and which methods it calls.
   - Call tree profiles - outputs results in the calltree format suitable for the KCacheGrind profiling tool.
+  - Many more -- see reports section of this README.
 * Threads - supports profiling multiple threads simultaneously
-* Recursive calls - supports profiling recursive method calls
-
 
 == Requirements
 
-ruby-prof requires Ruby 1.8.4 or higher.
+ruby-prof requires Ruby 1.8.7 or 1.9.1 and higher.
 
 If you are running Linux or Unix you'll need a C compiler so the extension
 can be compiled when it is installed.
 
-If you are running Windows, then you may need to install the 
-Windows specific RubyGem which includes an already built extension (see below).
+If you are running Windows, then you may need to install the
+Windows specific RubyGem which includes an already built extension (see Install section).
 
 == Install
 
 The easiest way to install ruby-prof is by using Ruby Gems.  To install:
 
-<tt>gem install ruby-prof</tt>
-
-If you on windows mswin [not mingw] (check via ruby -v) and 
-don't have an MSVC compiler, please install v0.7.3 which 
-has a prebuilt binary
-C:> gem install ruby-prof -v0.7.3
+  gem install ruby-prof
 
-If you're on mingw, please install the devkit first, then install the latest version (gem install ruby-prof).
+If you're on windows then a prebuilt binary gem is available.  You may of course
+compile it yourself via use of devkit on MinGW.
 
 == Usage
 
-There are three ways of running ruby-prof.
+There are two ways of running ruby-prof, via the command line or via its API.
 
 === ruby-prof executable
 
-The first is to use ruby-prof to run the Ruby program
-you want to profile.  For more information refer to
-the ruby-prof documentation[link:files/bin/ruby-prof.html].
+The first is to use ruby-prof to run the Ruby program you want to
+profile. For more information refer to the documentation of the
+ruby-prof command.
 
 
 === ruby-prof API
 
 The second way is to use the ruby-prof API to profile
-particular segments of code.  
+particular segments of code.
 
   require 'ruby-prof'
-  
+
   # Profile the code
   RubyProf.start
   ...
   [code to profile]
   ...
   result = RubyProf.stop
-  
+
   # Print a flat profile to text
   printer = RubyProf::FlatPrinter.new(result)
   printer.print(STDOUT)
-  
+
 Alternatively, you can use a block to tell ruby-prof what
 to profile:
 
   require 'ruby-prof'
-  
+
   # Profile the code
   result = RubyProf.profile do
     ...
     [code to profile]
     ...
   end
-  
+
   # Print a graph profile to text
   printer = RubyProf::GraphPrinter.new(result)
-  printer.print(STDOUT, 0)
+  printer.print(STDOUT, {})
 
-Starting with the 0.6.1 release, ruby-prof also supports pausing and resuming
-profiling runs.
+ruby-prof also supports pausing and resuming profiling runs.
 
   require 'ruby-prof'
-  
+
   # Profile the code
   RubyProf.start
   [code to profile]
@@ -96,59 +89,94 @@ profiling runs.
   RubyProf.resume
   [code to profile]
   result = RubyProf.stop
-  
+
 Note that resume will automatically call start if a profiling run
 has not yet started.  In addition, resume can also take a block:
 
   require 'ruby-prof'
-  
+
   # Profile the code
   RubyProf.resume do
     [code to profile]
   end
 
   data = RubyProf.stop
-  
-With this usage, resume will automatically call pause at the 
+
+With this usage, resume will automatically call pause at the
 end of the block.
 
 
-=== require unprof
+== Method and Thread Elimination
+
+ruby-prof supports eliminating specific methods and threads from profiling
+results. This is useful for reducing connectivity in the call graph, making it easier to
+identify the source of performance problems when using a graph printer.
+
+For example, consider Integer#times: it's hardly ever useful to know how much time is
+spent in the method itself. We're much more interested in how much the passed in block
+contributes to the time spent in the method which contains the Integer#times call.
+
+Methods are eliminated from the collected data by calling `eliminate_methods!` on the
+profiling result, before submitting it to a printer.
+
+  result = RubyProf.stop
+  result.eliminate_methods!([/Integer#times/])
+
+The argument given to `eliminate_methods!` is either an array of regular expressions, or
+the name of a file containing a list of regular expressions (line separated text).
+
+After eliminating methods the resulting profile will appear exactly as if those methods
+had been inlined at their call sites.
+
+In a similar manner, threads can be excluded so they are not profiled at all.  To do this,
+pass an array of threads to exclude to ruby-prof:
+
+  RubyProf::exclude_threads = [ thread2 ]
+  RubyProf.start
+
+Note that the excluded threads must be specified *before* profiling.
+
+
+== Benchmarking full load time including rubygems startup cost ==
+
+If you want to get a more accurate measurement of what takes all of a gem's bin/xxx
+command to load, you may want to also measure rubygems' startup penalty.
+You can do this by calling into bin/ruby-prof directly, ex:
 
-The third way of using ruby-prof is by requiring unprof.rb:
+$ gem which ruby-prof
+  g:/192/lib/ruby/gems/1.9.1/gems/ruby-prof-0.10.2/lib/ruby-prof.rb
 
-  require 'unprof'
+now run it thus (substitute lib/ruby-prof.rb with bin/ruby-prof):
 
-This will start profiling immediately and will output the results
-using a flat profile report.
+$ ruby g:/192/lib/ruby/gems/1.9.1/gems/ruby-prof-0.10.2/bin/ruby-prof g:\192\bin\some_installed_gem_command
 
-This method is provided for backwards compatibility.  Using
-{ruby-prof}[link:files/bin/ruby-prof.html] provides more flexibility.
+or
 
+$ ruby g:/192/lib/ruby/gems/1.9.1/gems/ruby-prof-0.10.2/bin/ruby-prof ./some_file_that_does_a_require_rubygems_at_the_beginning.rb
 
 == Profiling Tests
 
-Starting with the 0.6.1 release, ruby-prof supports profiling tests cases
-written using Ruby's built-in unit test framework (ie, test derived from 
-Test::Unit::TestCase).  To enable profiling simply add the following line 
+ruby-prof supports profiling tests cases
+written using Ruby's built-in unit test framework (ie, test derived from
+Test::Unit::TestCase).  To enable profiling simply add the following line
 of code to within your test class:
-  
-  	include RubyProf::Test
-  	
+
+        include RubyProf::Test
+
 Each test method is profiled separately.  ruby-prof will run each test method
 once as a warmup and then ten additional times to gather profile data.
-Note that the profile data will *not* include the class's setup or 
+Note that the profile data will *not* include the class's setup or
 teardown methods.
 
-Separate reports are generated for each method and saved, by default, 
+Separate reports are generated for each method and saved, by default,
 in the test process's working directory.  To change this, or other profiling
-options, modify your test class's PROFILE_OPTIONS hash table. To globally 
-change test profiling options, modify RubyProf::Test::PROFILE_OPTIONS.  
+options, modify your test class's PROFILE_OPTIONS hash table. To globally
+change test profiling options, modify RubyProf::Test::PROFILE_OPTIONS.
 
 
 == Profiling Rails
 
-To profile a Rails application it is vital to run it using production like 
+To profile a Rails application it is vital to run it using production like
 settings (cache classes, cache view lookups, etc.).  Otherwise, Rail's
 dependency loading code will overwhelm any time spent in the application
 itself (our tests show that Rails dependency loading causes a roughly 6x
@@ -157,49 +185,23 @@ profile.rb.
 
 So to profile Rails:
 
-1.  Create a new profile.rb environment - or simply copy the example file
-    in ruby-prof/rails/environment/profile.rb
-    
-2.  Copy the file:
-     
-      ruby-prof/rails/profile_test_helper.rb 
-    
-    To:
-    
-      your_rails_app/test/profile_test_helper.rb
-
-3.  Create a new test directory for profiling:
-
-      your_rails_app/test/profile
-    
-
-4.  Write unit, functional or integration tests specifically designed
-    to profile some part of your Rails application.  At the top
-    of each test, replace this line:
-    
-      require File.dirname(__FILE__) + '/../test_helper'
-
-    With:
-    
-      require File.dirname(__FILE__) + '/../profile_test_helper'
-
-    For example:
-
-    require File.dirname(__FILE__) + '/../profile_test_helper'
-    
-    class ExampleTest < Test::Unit::TestCase
-      include RubyProf::Test
-      fixtures ....
-      
-      def test_stuff
-        puts "Test method"
-      end
-    end   
-
-5.  Now run your tests.  Results will be written to:
-
-      your_rails_app/tmp/profile
-    
+1.  Create a new profile.rb environment.  Make sure to turn on cache_classes
+and cache_template_loading.  Otherwise your profiling results will be
+overwhelemed by the time Rails spends loading required files.
+
+2.  Add the ruby prof rack adapter to your middleware stack.  One way to
+do this is by adding the following code to config.ru:
+
+  if Rails.env.profile?
+    use Rack::RubyProf, :path => '/temp/profile'
+  end
+
+The path is where you want profiling results to be stored.  By default the
+rack adapter will generate a html call graph report and flat text report.
+
+3.  Now make a request to your running server.  New profiling information will
+be generated for each request.  Note that each request will overwrite
+the profiling reports created by the previous request!
 
 == Reports
 
@@ -209,36 +211,46 @@ ruby-prof can generate a number of different reports:
 * Graph Reports
 * HTML Graph Reports
 * Call graphs
+* Call stack reports
+* More!
 
-Flat profiles show the overall time spent in each method.  They
+Flat profiles show the overall time spent in each method. They
 are a good of quickly identifying which methods take the most time.
 An example of a flat profile and an explanation can be found in
-{examples/flat.txt}[link:files/examples/flat_txt.html].
-
-Graph profiles also show the overall time spent in each method.
-In addition, they also show which methods call the current
-method and which methods its calls.  Thus they are good for
-understanding how methods gets called and provide insight into
-the flow of your program.  An example text graph profile
-is located at {examples/graph.txt}[link:files/examples/graph_txt.html].
-
-HTML Graph profiles are the same as graph profiles, except
-output is generated in hyper-linked HTML. Since graph profiles
-can be quite large, the embedded links make it much easier to
-navigate the results.  An example html graph profile
-is located at {examples/graph.html}[link:files/examples/graph_html.html].
-
-HTML Graph profiles are the same as graph profiles, except
-output is generated in hyper-linked HTML. Since graph profiles
-can be quite large, the embedded links make it much easier to
-navigate the results.  An example html graph profile
-is located at {examples/graph.html}[link:files/examples/graph_html.html].
+{examples/flat.txt}[http://github.com/rdp/ruby-prof/tree/master/examples/flat.txt].
+
+There are several varieties of these -- run $ ruby-prof --help
+
+Graph profiles also show the overall time spent in each method. In
+addition, they also show which methods call the current method and which
+methods its calls.  Thus they are good for understanding how methods
+gets called and provide insight into the flow of your program. An
+example text graph profile is located at
+{examples/graph.txt}[http://github.com/rdp/ruby-prof/tree/master/examples/graph.txt].
+
+HTML Graph profiles are the same as graph profiles, except output is
+generated in hyper-linked HTML. Since graph profiles can be quite large,
+the embedded links make it much easier to navigate the results. An
+example html graph profile is located at
+{examples/graph.html}[http://github.com/rdp/ruby-prof/tree/master/examples/graph.html].
 
 Call graphs output results in the calltree profile format which is used
-by KCachegrind.  Call graph support was generously donated by Carl Shimer.
-More information about the format can be found at
-the {KCachegrind}[link:http://kcachegrind.sourceforge.net/cgi-bin/show.cgi/KcacheGrindCalltreeFormat] site.
+by KCachegrind. Call graph support was generously donated by Carl
+Shimer. More information about the format can be found at the
+{KCachegrind}[http://kcachegrind.sourceforge.net/cgi-bin/show.cgi/KcacheGrindCalltreeFormat]
+site.
+
+Call stack reports produce a HTML visualization of the time spent in
+each execution path of the profiled code. An example can be found at
+{examples/stack.html}[http://github.com/rdp/ruby-prof/tree/master/examples/call_stack.html].
+
+Another good example: [http://twitpic.com/28z94a]
+
+Finally, there's a so called MultiPrinter which can generate several
+reports in one profiling run. See
+{examples/multi.stack.html}[http://github.com/rdp/ruby-prof/tree/master/examples/multi.stack.html].
 
+There is also a graphviz .dot visualiser.
 
 == Printers
 
@@ -248,7 +260,11 @@ Reports are created by printers.  Supported printers include:
 * RubyProf::FlatPrinterWithLineNumbers - same as above but more verbose
 * RubyProf::GraphPrinter - Creates a call graph report in text format
 * RubyProf::GraphHtmlPrinter - Creates a call graph report in HTML (separate files per thread)
+* RubyProf::DotPrinter - Creates a call graph report in GraphViz's DOT format which can be converted to an image
 * RubyProf::CallTreePrinter - Creates a call tree report compatible with KCachegrind.
+* RubyProf::CallStackPrinter - Creates a HTML visualization of the Ruby stack
+* RubyProf::MultiPrinter - Uses the other printers to create several reports in one profiling run
+* More!
 
 To use a printer:
 
@@ -258,13 +274,20 @@ To use a printer:
   printer.print(STDOUT, :min_percent => 2)
 
 The first parameter is any writable IO object such as STDOUT or a file.
-The second parameter, specifies the minimum percentage a method must take 
-to be printed.  Percentages should be specified as integers in the range 0 to 100.  
+The second parameter, specifies the minimum percentage a method must take
+to be printed.  Percentages should be specified as integers in the range 0 to 100.
 For more information please see the documentation for the different printers.
 
 The other option is :print_file => true (default false), which adds the filename to the
 output (GraphPrinter only).
 
+The MultiPrinter differs from the other printers in that it requires a directory path
+and a basename for the files it produces.
+
+   printer = RubyProf::MultiPrinter.new(result)
+   printer.print(:path => ".", :profile => "profile")
+
+
 == Measurements
 
 Depending on the mode and platform, ruby-prof can measure various
@@ -279,7 +302,7 @@ aspects of a Ruby program.  Supported measurements include:
 * garbage collection time (RubyProf::GC_TIME)
 
 Process time measures the time used by a process between any two moments.
-It is unaffected by other processes concurrently running 
+It is unaffected by other processes concurrently running
 on the system. Note that Windows does not support measuring process
 times - therefore, measurements on Windows defaults to wall time.
 
@@ -335,17 +358,15 @@ environment variable:
 * export RUBY_PROF_MEASURE_MODE=memory
 * export RUBY_PROF_MEASURE_MODE=gc_runs
 * export RUBY_PROF_MEASURE_MODE=gc_time
-  
-Note that these values have changed since ruby-prof-0.3.0.  
 
-On Linux, process time is measured using the clock method provided 
+On Linux, process time is measured using the clock method provided
 by the C runtime library. Note that the clock method does not
 report time spent in the kernel or child processes and therefore
 does not measure time spent in methods such as Kernel.sleep method.
 If you need to measure these values, then use wall time.  Wall time
 is measured using the gettimeofday kernel method.
 
-On Windows, timings default to wall times.  If you set the clock 
+On Windows, timings default to wall times.  If you set the clock
 mode to PROCESS_TIME, then timing are read using the clock method
 provided by the C runtime library.  Note though, these values are
 wall times on Windows and not process times like on Linux.
@@ -354,62 +375,35 @@ Wall time is measured using the GetLocalTime API.
 If you use wall time, the results will be affected by other
 processes running on your computer, network delays, disk access,
 etc.  As result, for the best results, try to make sure your
-computer is only performing your profiling run and is 
+computer is only performing your profiling run and is
 otherwise quiescent.
 
 On both platforms, cpu time is measured using the RDTSC assembly
 function provided by the Pentium and PowerPC platforms. CPU time
-is dependent on the cpu's frequency.  On Linux, ruby-prof attempts 
+is dependent on the cpu's frequency.  On Linux, ruby-prof attempts
 to read this value from "/proc/cpuinfo."  On Windows, you must
 manually specify the clock frequency.  This can be done using the
 RUBY_PROF_CPU_FREQUENCY environment variable:
 
   export RUBY_PROF_CPU_FREQUENCY=<value>
-  
-You can also directly set the cpu frequency by calling:
-
-  RubyProf.cpu_frequency = <value> 
-
 
-== Recursive Calls
-
-Recursive calls occur when method A calls method A and cycles
-occur when method A calls method B calls method C calls method A.
-ruby-prof detects both direct recursive calls and cycles.  Both
-are indicated in reports by a "d number" in parentheses following a method
-name.  For example, here is a flat profile from the test method
-
-RecursiveTest#test_recursive:
-
-%self     total     self     wait    child    calls  name
-100.00      2.00     2.00     0.00     0.00        2  Kernel#sleep
-  0.00      2.00     0.00     0.00     2.00        0  RecursiveTest#test_cycle
-  0.00      0.00     0.00     0.00     0.00        2  Fixnum#==
-  0.00      0.00     0.00     0.00     0.00        2  Fixnum#-
-  0.00      1.00     0.00     0.00     1.00        1  Object#sub_cycle(d1)
-  0.00      2.00     0.00     0.00     2.00        1  Object#sub_cycle
-  0.00      2.00     0.00     0.00     2.00        1  Object#cycle
-  0.00      1.00     0.00     0.00     1.00        1  Object#cycle(d1)
+You can also directly set the cpu frequency by calling:
 
-Notice the presence of Object#cycle and Object#cycle(d1).  The d1 means
-depth 1 -- the method was either recursively called (directly or indirectly).
+  RubyProf.cpu_frequency = <value>
 
-However, the self time values for recursive calls should always 
-be accurate.  It is also believed that the total times are
-accurate, but these should be carefully analyzed to verify their veracity.
 
 == Multi-threaded Applications
 
 Unfortunately, Ruby does not provide an internal api
 for detecting thread context switches in 1.8.  As a result, the
 timings ruby-prof reports for each thread may be slightly
-inaccurate.  In particular, this will happen for newly 
-spawned threads that go to sleep immediately (their first call).  
+inaccurate.  In particular, this will happen for newly
+spawned threads that go to sleep immediately (their first call).
 For instance, if you use Ruby's timeout library to wait for 2 seconds,
 the 2 seconds will be assigned to the foreground thread
 and not the newly created background thread.  These errors
 can largely be avoided if the background thread performs any
-operation before going to sleep. 
+operation before going to sleep.
 
 == Performance
 
@@ -420,13 +414,12 @@ profiled.  Most programs will run approximately twice as slow
 while highly recursive programs (like the fibonacci series test)
 will run three times slower.
 
-Because of some threading difficulties in 1.9, it currently runs a bit slower there.
-http://www.ruby-forum.com/topic/201329
-
 == License
 
 See LICENSE for license information.
 
 == Development
 
-Code is located at http://github.com/rdp/ruby-prof
+Code is located at http://github.com/rdp/ruby-prof
+
+Google group/mailing list: http://groups.google.com/group/ruby-optimization