Profile: on Windows, sample at 10ms intervals.

See discussion starting at https://groups.google.com/d/msg/julia-users/hNEJtracCuI/bTaKlrKLIAcJ

base/profile.jl

@@ -41,7 +41,7 @@ end
 
 # init with default values
 # Use a max size of 1M profile samples, and fire timer every 1ms
-__init__() = init(1_000_000, 0.001)
+@windows? (__init__() = init(1_000_000, 0.01)) : (__init__() = init(1_000_000, 0.001))
 
 clear() = ccall(:jl_profile_clear_data, Void, ())
 

doc/stdlib/profile.rst

@@ -27,16 +27,22 @@ sequence of function calls up to and including this line---is
 proportional to how often it appears in the set of all backtraces.
 
 A sampling profiler does not provide complete line-by-line coverage,
-because the backtraces occur at intervals (by default, 1 ms). However,
-this design has important strengths:
+because the backtraces occur at intervals (by default, 1 ms on Unix
+systems and 10 ms on Windows, although the actual scheduling is
+subject to operating system load). Moreover, as discussed further
+below, because samples are collected at a sparse subset of all
+execution points, the data collected by a sampling profiler is subject
+to statistical noise.
+
+Despite these limitations, sampling profilers have substantial strengths:
 
 - You do not have to make any modifications to your code to take
  timing measurements (in contrast to the alternative `instrumenting
  profiler <https://github.com/timholy/IProfile.jl>`_).
 - It can profile into Julia's core code and even (optionally) into C
  and Fortran libraries.
 - By running "infrequently" there is very little performance overhead;
- while profiling, your code will run at nearly native speed.
+ while profiling, your code can run at nearly native speed.
 
 For these reasons, it's recommended that you try using the built-in
 sampling profiler before considering any alternatives.