code:profiling
Differences
This shows you the differences between two versions of the page.
|
code:profiling [2017/12/22 14:25] phil |
code:profiling [2020/03/29 12:13] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Profiling ====== | ||
| - | |||
| - | A collection of code profiling techniques follows. | ||
| - | |||
| - | ===== Dynamic Memory Allocation ===== | ||
| - | |||
| - | The biggest problems with dynamic memory management are: | ||
| - | - leaks and | ||
| - | - corruption. | ||
| - | While the later is rather tricky to analyse, for memleaks there is | ||
| - | ''valgrind''. Invocation as follows: | ||
| - | <code> | ||
| - | $ gcc -g test.c | ||
| - | $ valgrind --leak-check=full ./a.out | ||
| - | </code> | ||
| - | |||
| - | ===== Performance ===== | ||
| - | |||
| - | When programming, the code complexity (O-notation) is the main factor | ||
| - | identifying CPU-intense algorithms. Reducing the code's complexity often | ||
| - | doesn't suffice, though. E.g. IO-intense operations often lead to delays at | ||
| - | run-time which isn't covered by the O-notation, at all. This means that aside | ||
| - | of complexity analysis, there always should be run-time code execution time | ||
| - | measurement. And this is where ''gprof'' comes into action: | ||
| - | <code> | ||
| - | $ gcc -pg -g test.c | ||
| - | $ ./a.out | ||
| - | $ gprof a.out gmon.out | ||
| - | </code> | ||
| - | |||
| - | ==== Python ==== | ||
| - | |||
| - | Profiling Python is pretty simple, using cPython module: | ||
| - | <code> | ||
| - | $ python -m cPython myscript.py | ||
| - | </code> | ||
| - | |||
| - | ===== Coverage ===== | ||
| - | |||
| - | Code coverage means to have a look at how often each line of code is being | ||
| - | executed. Interestingly, this can be used to "measure" the code's complexity. | ||
| - | This way a broader view over the problem can be provided, e.g. answering the | ||
| - | question if a seldomly executed O(n) algorithm is heavier than an O(log(n)) | ||
| - | one being executed all the time. One of the best tools to analyse the code | ||
| - | coverage is ''gcov'': | ||
| - | <code> | ||
| - | $ gcc -fprofile-arcs -ftest-coverage test.c | ||
| - | $ ./a.out | ||
| - | $ gcov tmp.c | ||
| - | </code> | ||
| - | this will create the file //test.c.gcov// containing the annotated source code | ||
| - | of //test.c//. | ||
| - | |||
code/profiling.txt · Last modified: 2020/03/29 12:13 (external edit)
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
