RST backtick refactor (all *.rst except manual.rst and rst_examples.rst) (#17258)

Co-authored-by: quantimnot <quantimnot@users.noreply.github.com>
This commit is contained in:
quantimnot 2021-03-18 23:37:55 -04:00 • committed by GitHub
commit 83ae70cb54
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
30 changed files with 1402 additions and 1350 deletions

View file

@ -1,3 +1,5 @@
.. default-role:: code
===================================================
Embedded Stack Trace Profiler (ESTP) User Guide
===================================================
@ -10,21 +12,21 @@ Nim comes with a platform independent profiler -
the Embedded Stack Trace Profiler (ESTP). The profiler
is *embedded* into your executable. To activate the profiler you need to do:
* compile your program with the ``--profiler:on --stackTrace:on`` command
* compile your program with the `--profiler:on --stackTrace:on` command
line options
* import the ``nimprof`` module
* import the `nimprof` module
* run your program as usual.
You can in fact look at ``nimprof``'s source code to see how to implement
You can in fact look at `nimprof`'s source code to see how to implement
your own profiler.
The setting ``--profiler:on`` defines the conditional symbol ``profiler``.
The setting `--profiler:on` defines the conditional symbol `profiler`.
After your program has finished the profiler will create a
file ``profile_results.txt`` containing the profiling results.
file `profile_results.txt` containing the profiling results.
Since the profiler works by examining stack traces, it's essential that
the option ``--stackTrace:on`` is active! Unfortunately this means that a
the option `--stackTrace:on` is active! Unfortunately this means that a
profiling build is much slower than a release build.
@ -35,12 +37,12 @@ You can also use ESTP as a memory profiler to see which stack traces allocate
the most memory and thus create the most GC pressure. It may also help to
find memory leaks. To activate the memory profiler you need to do:
* compile your program with the ``--profiler:off --stackTrace:on -d:memProfiler``
command line options. Yes it's ``--profiler:off``.
* import the ``nimprof`` module
* compile your program with the `--profiler:off --stackTrace:on -d:memProfiler`
command line options. Yes it's `--profiler:off`.
* import the `nimprof` module
* run your program as usual.
Define the symbol ``ignoreAllocationSize`` so that only the number of
Define the symbol `ignoreAllocationSize` so that only the number of
allocations is counted and the sizes of the memory allocations do not matter.
@ -51,7 +53,7 @@ The results file lists stack traces ordered by significance.
The following example file has been generated by profiling the Nim compiler
itself: It shows that in total 5.4% of the runtime has been spent
in ``crcFromRope`` or its children.
in `crcFromRope` or its children.
In general the stack traces show you immediately where the problem is because
the trace acts like an explanation; in traditional profilers you can only find