| 32 | We now ship a wrapper which takes care of simplifying the calls to {{{pycallgraph}}}: |
| 33 | {{{ |
| 34 | ./tests/scripts/xpra/pycallgraph |
| 35 | }}} |
| 36 | This command includes a number of working examples and lists the groups and threads available for profiling. |
| 37 | |
| 38 | === Using pycallgraph to identify bottlenecks == |
| 39 | General guidelines: |
| 40 | * start with a small delay (ie: {{{-d 2}}}) to skip the initial setup, potentially longer if you start a server and then also need to connect the client before profiling |
| 41 | * when comparing versions/changes/settings: use the runtime parameter to ensure that each run will last for exactly the same amount of time - this makes it easier to compare the labels using absolute values, and script the whole thing so the client connects at exactly the same time if profiling the server |
| 42 | * focus on one thread at a time - there is not much overlap/impact between different threads |
| 43 | * choose an application to test which will stress the desired portion of the code (ie: if testing the network or encoding thread, an application that generates a high frames-per-second is more appropriate than what may ultimately be the target application for the system) |
| 44 | * choose an application whose behaviour is predictable: preferably not using the network or relying on any external resources |
| 45 | * start with most groups enabled |
| 46 | * most groups can usually be disabled early - unless they are being profiled specifically |
| 47 | * some [./Debugging Debugging] environment variables may be useful |