[perl-devel-nytprof] r1434 committed - Corrected spelling thanks to Alessandro Ghedini @debian RT80370

[perl-deve...@googlecode.com]

Revision: 1434
Author: tim....@gmail.com
Date: Wed Oct 24 02:00:20 2012
Log: Corrected spelling thanks to Alessandro Ghedini @debian RT80370

http://code.google.com/p/perl-devel-nytprof/source/detail?r=1434

Modified:
/trunk/Changes
/trunk/lib/Devel/NYTProf.pm

=======================================
--- /trunk/Changes Sat Sep 15 03:21:09 2012
+++ /trunk/Changes Wed Oct 24 02:00:20 2012
@@ -6,6 +6,13 @@

=cut

+TODO: study http://www.postgresql.org/docs/9.2/static/pgtesttiming.html
+and reference in our docs.
+
+=head2 Changes in Devel::NYTProf 4.10
+
+ Corrected spelling thanks to Alessandro Ghedini @debian RT80370
+
=head2 Changes in Devel::NYTProf 4.09 (svn 1431) 15th Sep 2012

Fixed to work for perl v5.17.3+ thanks to David Mitchell.
=======================================
--- /trunk/lib/Devel/NYTProf.pm Sun Sep 16 04:31:07 2012
+++ /trunk/lib/Devel/NYTProf.pm Wed Oct 24 02:00:20 2012
@@ -469,7 +469,7 @@
less accurate timings.

Most systems have a 0.01 second granularity in the results from the
C<times()>
-sytem call. With modern processors having multi- gigahertz clocks, 0.01
+system call. With modern processors having multi- gigahertz clocks, 0.01
seconds is like a lifetime. The 'ticks' of this CPU time clock
happen so rarely relative to the activity of a most applications that you'd
have to run the code for many hours to have any hope of reasonably useful
results.
@@ -1158,7 +1158,7 @@
There are two likely causes for this: clock instability, or accumulated
timing
errors.

-Clock instability, if present on your system, is most likely to be
noticable on
+Clock instability, if present on your system, is most likely to be
noticeable on
very small/fast subroutines that are called very few times.

Accumulated timing errors can arise because the subroutine profiler uses