feedc0de/qt-creator
1
0
Fork 0
forked from qt-creator/qt-creator
Code Pull Requests Activity

Doc: Restructure the "Analyzing Code" section

Browse Source 
- Turn the topics into how-to and reference topics.
- Rewrite "Analyzing Code" as an overview topic.

Task-number: QTCREATORBUG-29361
Change-Id: Id02253514cd1dcd808f040ced7f9f73f6db5e113
Reviewed-by: hjk <hjk@qt.io>
This commit is contained in:
Leena Miettinen
2024-04-15 12:13:01 +02:00
parent 20e332b135
commit afc8816589
18 changed files with 404 additions and 358 deletions
Download Patch File Download Diff File Expand all files Collapse all files

BIN
doc/qtcreator/images/qtcreator-heob-in-terminal.webp Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 5.1 KiB

BIN
doc/qtcreator/images/qtcreator-heob.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 24 KiB

274
doc/qtcreator/src/analyze/cpu-usage-analyzer.qdoc
View File

@@ -1,4 +1,4 @@
// Copyright (C) 2022 The Qt Company Ltd.
// Copyright (C) 2024 The Qt Company Ltd.
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GFDL-1.3-no-invariants-only
// **********************************************************************
@@ -8,136 +8,151 @@
// **********************************************************************
/*!
\previouspage creator-heob.html
\page creator-cpu-usage-analyzer.html
\nextpage creator-cppcheck.html
\page creator-how-to-analyze-cpu-usage.html
\previouspage creator-how-tos.html
\title Analyzing CPU Usage
\ingroup creator-how-to-analyze
\QC is integrated with the Linux Perf tool that can be
used to analyze the CPU and memory usage of an application on embedded
devices and, to a limited extent, on Linux desktop platforms. The
Performance Analyzer uses the Perf tool bundled with the Linux kernel to
take periodic snapshots of the call chain of an application and visualizes
them in a timeline view or as a flame graph.
\title Analyze CPU usage
\section1 Using the Performance Analyzer
With Perf, you can analyze the CPU and memory usage of an application
on Linux desktop and embedded devices. \l{Performance Analyzer} uses the
Perf tool bundled with the Linux kernel to take periodic snapshots of
the call chain of an application and visualizes them in a timeline view
or as a flame graph.
The Performance Analyzer usually needs to be able to locate debug symbols for
the binaries involved.
Usually, Performance Analyzer needs debug symbols for the profiled
binaries. Profile builds produce optimized binaries with separate debug
symbols, so use them for profiling.
Profile builds produce optimized binaries with separate debug symbols and
should generally be used for profiling.
\section1 Collect data
To manually set up a build configuration that generates separate debug
symbols, edit the project build settings:
\list 1
\li To generate debug symbols also for applications compiled in release
mode, select \uicontrol {Projects}, and then select
\uicontrol Enable in the \uicontrol {Separate debug info} field.
\li Select \uicontrol Yes to recompile the project.
\endlist
You can start the Performance Analyzer in the following ways:
Start Performance Analyzer in the following ways to collect data:
\list
\li Select \uicontrol Analyze > \uicontrol {Performance Analyzer} to
\li Go to \uicontrol Analyze > \uicontrol {Performance Analyzer} to
profile the current application.
\li Select the
\inlineimage icons/qtcreator-analyze-start-button.png
(\uicontrol Start) button to start the application from the
\li Select \inlineimage icons/qtcreator-analyze-start-button.png
(\uicontrol Start) to start the application from the
\uicontrol {Performance Analyzer}.
\image qtcreator-performance-analyzer-toolbar.png {Performance Analyzer toolbar}
\endlist
\note If data collection does not start automatically, select the
\note If data collection does not start automatically, select
\inlineimage icons/recordfill.png
(\uicontrol {Collect profile data}) button.
(\uicontrol {Collect profile data}).
When you start analyzing an application, the application is launched, and
the Performance Analyzer immediately begins to collect data. This is indicated
by the time running in the \uicontrol Recorded field. However, as the data
Performance Analyzer immediately begins to collect data. This is indicated
by the time running in \uicontrol Recorded. However, as the data
is passed through the Perf tool and an extra helper program bundled with
\QC, and both buffer and process it on the fly, data may arrive in \QC
several seconds after it was generated. An estimate for this delay is given
in the \uicontrol {Processing delay} field.
several seconds after it was generated. \uicontrol {Processing delay} shows
an estimate of the delay.
Data is collected until you select the
\uicontrol {Stop collecting profile data} button or terminate the
application.
Data is collected until you select \inlineimage icons/recordfill.png
(\uicontrol {Stop collecting profile data}) or close the application.
Select the \uicontrol {Stop collecting profile data} button to disable the
Select \uicontrol {Stop collecting profile data} to turn off the
automatic start of the data collection when an application is launched.
Profile data will still be generated, but \QC will discard it until you
Profile data is still generated, but \QC discards it until you
select the button again.
\section1 Profiling Memory Usage on Devices
\section1 Profile memory usage on devices
To create trace points for profiling memory usage on a target device, select
\uicontrol Analyze > \uicontrol {Performance Analyzer Options} >
\uicontrol {Create Memory Trace Points} or select
\inlineimage icons/create-tracepoint.png
on the \uicontrol {Performance Analyzer} toolbar.
To create trace points for profiling memory usage on a target device:
In the \uicontrol {Create Memory Trace Points} dialog, you can modify the
\list
\li Go to \uicontrol Analyze > \uicontrol {Performance Analyzer Options}
> \uicontrol {Create Memory Trace Points}.
\li Select \inlineimage icons/create-tracepoint.png
on the \uicontrol {Performance Analyzer} toolbar.
\endlist
In the \uicontrol {Create Memory Trace Points} dialog, modify the
script to run.
\image qtcreator-performance-analyzer-create-memory-trace-points.png "Create Memory Trace Points dialog"
\image qtcreator-performance-analyzer-create-memory-trace-points.png {Create Memory Trace Points dialog}
If you need root privileges to run scripts as root, select the privileges to
use in the \uicontrol {Elevate privileges using} field.
use in \uicontrol {Elevate privileges using}.
Select \uicontrol OK to run the script.
To add events for the trace points, see \l{Choosing Event Types}.
You can record a memory trace to view usage graphs in the samples rows of
Record a memory trace to view usage graphs in the samples rows of
the timeline and to view memory allocations, peaks, and releases in the
flame graph.
\section1 Specifying Performance Analyzer Settings
\section1 Generate separate debug info for qmake projects
To specify global settings for the Performance Analyzer, select
\preferences > \uicontrol Analyzer >
\uicontrol {CPU Usage}. For each run configuration, you can also
use specialized settings. Select \uicontrol Projects > \uicontrol Run, and
then select \uicontrol Details next to
\uicontrol {Performance Analyzer Settings}.
To manually set up a build configuration that generates debug symbols also
for applications compiled for release, edit the build settings of a qmake
project:
\image qtcreator-performance-analyzer-settings.png
\list 1
\li Go to \uicontrol {Projects} > \uicontrol {Build Settings}.
\li In \uicontrol {Separate debug info}, select \uicontrol Enable.
\li Select \uicontrol Yes to recompile the project.
\endlist
To edit the settings for the current run configuration, you can also select
the dropdown menu next to the \uicontrol {Collect profile data} button.
\sa {Analyze}{How To: Analyze}, {Analyzers}, {Performance Analyzer},
{Analyzing Code}
*/
\section2 Choosing Event Types
/*!
\page creator-cpu-usage-analyzer.html
\previouspage creator-reference.html
In the \uicontrol Events table, you can specify which events should trigger
the Performance Analyzer to take a sample. The most common way of analyzing
\ingroup creator-reference-analyzer
\title Performance Analyzer
\brief Analyze the CPU and memory usage of an application on Linux desktop
and embedded devices.
To set global preferences for Performance Analyzer, go to \preferences >
\uicontrol Analyzer > \uicontrol {CPU Usage}.
To set preferences for a particular run configuration, go to
\uicontrol Projects > \uicontrol Run, and then select \uicontrol Details
next to \uicontrol {Performance Analyzer Settings}.
\image qtcreator-performance-analyzer-settings.png {Performance Analyzer Settings}
To edit the settings for the current run configuration, select the
drop down menu next to \inlineimage icons/recordfill.png on the
Performance Analyzer toolbar.
\image qtcreator-performance-analyzer-toolbar.png {Performance Analyzer toolbar}
\section1 Choosing Event Types
The events table lists the events that trigger Performance Analyzer to take
a sample. The most common way of analyzing
CPU usage involves periodic sampling, driven by hardware performance
counters that react to the number of instructions or CPU cycles executed.
Alternatively, a software counter that uses the CPU clock can be chosen.
You can also select a software counter that uses the CPU clock.
Select \uicontrol {Add Event} to add events to the table.
In the \uicontrol {Event Type} column, you can choose the general type of
In \uicontrol {Event Type}, select the general type of
event to be sampled, most commonly \uicontrol {hardware} or
\uicontrol {software}. In the \uicontrol {Counter} column, you can choose
which specific counter should be used for the sampling. For example,
\uicontrol {software}. In \uicontrol {Counter}, select the counter
for the sampling. For example,
\uicontrol {instructions} in the \uicontrol {hardware} group or
\uicontrol {cpu-clock} in the \uicontrol {software} group.
More specialized sampling, for example by cache misses or cache hits, is
possible. However, support for it depends on specific features of the CPU
involved. For those specialized events, you can give more detailed sampling
instructions in the \uicontrol {Operation} and \uicontrol {Result} columns.
For example, you can choose a \uicontrol {cache} event for
possible. However, support for it depends on specific features of the CPU.
For those specialized events, give more detailed sampling
instructions in \uicontrol {Operation} and \uicontrol {Result}.
For example, select a \uicontrol {cache} event for
\uicontrol {L1-dcache} on the \uicontrol {load} operation with a result
of \uicontrol {misses}. That would sample L1-dcache misses on reading.
of \uicontrol {misses} to sample L1-dcache misses on reading.
Select \uicontrol {Remove Event} to remove the selected event from the
table.
@@ -145,29 +160,28 @@
Select \uicontrol {Use Trace Points} to replace the current selection of
events with trace points defined on the target device and set the
\uicontrol {Sample mode} to \uicontrol {event count} and the
\uicontrol {Sample period} to \c {1}. If the trace points on the target
were defined using the \uicontrol {Create Trace Points} option, the
Performance Analyzer will automatically use them to profile memory usage.
\uicontrol {Sample period} to \c {1}. If \uicontrol {Create Trace Points}
defines the trace points on the target, Performance Analyzer automatically
uses them to profile memory usage.
Select \uicontrol {Reset} to revert the selection of events, as well as the
Select \uicontrol {Reset} to revert the selection of events, as well as
\uicontrol {Sample mode} and \uicontrol {Sample period} to the default
values.
\section2 Choosing a Sampling Mode and Period
\section1 Choosing a Sampling Mode and Period
In the \uicontrol {Sample mode} and \uicontrol {Sample period} fields, you
can specify how samples are triggered:
In \uicontrol {Sample mode} and \uicontrol {Sample period}, specify how
samples are triggered:
\list
\li Sampling by \uicontrol {event count} instructs the kernel to take
a sample every \c n times one of the chosen events has occurred,
where \c n is specified in the \uicontrol {Sample period} field.
where \c n is set in \uicontrol {Sample period}.
\li Sampling by \uicontrol {frequency (Hz)} instructs the kernel to try and
take a sample \c n times per second, by automatically adjusting the
sampling period. Specify \c n in the \uicontrol {Sample period}
field.
sampling period. Set \c n in \uicontrol {Sample period}.
\endlist
@@ -178,15 +192,15 @@
There may be a significant difference between the sampling period you
request and the actual result.
In general, if you configure the Performance Analyzer to collect more data
In general, if you configure Performance Analyzer to collect more data
than it can transmit over the connection between the target and the host
device, the application may get blocked while Perf is trying to send the
data, and the processing delay may grow excessively. You should then change
the \uicontrol {Sample period} or the \uicontrol {Stack snapshot size}.
the value of \uicontrol {Sample period} or \uicontrol {Stack snapshot size}.
\section2 Selecting Call Graph Mode
\section1 Selecting Call Graph Mode
In the \uicontrol {Call graph mode} field, you can specify how the
In \uicontrol {Call graph mode}, you can specify how
Performance Analyzer recovers call chains from your application:
\list
@@ -210,32 +224,32 @@
Qt and most system libraries are compiled without frame pointers by
default, so the frame pointer mode is only useful with customized systems.
\section2 Setting Stack Snapshot Size
\section1 Setting Stack Snapshot Size
The Performance Analyzer will analyze and \e unwind the stack snapshots
generated by Perf in dwarf mode. Set the size of the stack snapshots in the
\uicontrol {Stack snapshot size} field. Large stack snapshots result in a
Performance Analyzer analyzes and \e unwinds the stack snapshots
generated by Perf in dwarf mode. Set the size of the stack snapshots in
\uicontrol {Stack snapshot size}. Large stack snapshots result in a
larger volume of data to be transferred and processed. Small stack
snapshots may fail to capture call chains of highly recursive applications
or other intense stack usage.
\section2 Adding Command-Line Options for Perf
\section1 Adding Command-Line Options for Perf
You can specify additional command-line options to be passed to Perf when
recording data in the \uicontrol {Additional arguments} field. You may want
to specify \c{--no-delay} or \c{--no-buffering} to reduce the processing
Set additional command-line options to pass to Perf when
recording data in \uicontrol {Additional arguments}. Set \c{--no-delay}
or \c{--no-buffering} to reduce the processing
delay. However, those options are not supported by all versions of Perf and
Perf may not start if an unsupported option is given.
\section2 Resolving Names for JIT-compiled JavaScript Functions
\section1 Resolving Names for JIT-compiled JavaScript Functions
Since version 5.6.0, Qt can generate perf.map files with information about
JavaScript functions. The Performance Analyzer will read them and show the
JavaScript functions. Performance Analyzer will read them and show the
function names in the \uicontrol Timeline, \uicontrol Statistics, and
\uicontrol {Flame Graph} views. This only works if the process being
profiled is running on the host computer, not on the target device. To
switch on the generation of perf.map files, add the environment variable
\c QV4_PROFILE_WRITE_PERF_MAP to the \uicontrol {Run Environment} and set
\c QV4_PROFILE_WRITE_PERF_MAP to \uicontrol {Run Environment} and set
its value to \c 1.
\section1 Analyzing Collected Data
@@ -243,36 +257,35 @@
The \uicontrol Timeline view displays a graphical representation of CPU
usage per thread and a condensed view of all recorded events.
\image qtcreator-performance-analyzer-timeline.png "Performance Analyzer"
\image qtcreator-performance-analyzer-timeline.png {Performance Analyzer}
Each category in the timeline describes a thread in the application. Move
the cursor on an event (5) on a row to see how long it takes and which
function in the source it represents. To display the information only when
an event is selected, disable the
\uicontrol {View Event Information on Mouseover} button (4).
an event is selected, turn off
\uicontrol {View Event Information on Mouseover} (4).
The outline (9) summarizes the period for which data was collected. Drag
the zoom range (7) or click the outline to move on the outline. You can
also move between events by selecting the
\uicontrol {Jump to Previous Event} and \uicontrol {Jump to Next Event}
buttons (1).
also move between events by selecting \uicontrol {Jump to Previous Event}
and \uicontrol {Jump to Next Event} (1).
Select the \uicontrol {Show Zoom Slider} button (2) to open a slider that
you can use to set the zoom level. You can also drag the zoom handles (8).
Select \uicontrol {Show Zoom Slider} button (2) to open a slider that
sets the zoom level. You can also drag the zoom handles (8).
To reset the default zoom level, right-click the timeline to open the
context menu, and select \uicontrol {Reset Zoom}.
\section2 Selecting Event Ranges
You can select an event range (6) to view the time it represents or to zoom
into a specific region of the trace. Select the \uicontrol {Select Range}
button (3) to activate the selection tool. Then click in the timeline to
Select an event range (6) to view the time it represents or to zoom
into a specific region of the trace. Select \uicontrol {Select Range}
(3) to activate the selection tool. Then click in the timeline to
specify the beginning of the event range. Drag the selection handle to
define the end of the range.
You can use event ranges also to measure delays between two subsequent
Use event ranges also to measure delays between two subsequent
events. Place a range between the end of the first event and the beginning
of the second event. The \uicontrol Duration field displays the delay
of the second event. \uicontrol Duration shows the delay
between the events in milliseconds.
To zoom into an event range, double-click it.
@@ -294,10 +307,10 @@
events to move the cursor in the code editor to the part of the code the
event is associated with.
As the Perf tool only collects periodic samples, the Performance Analyzer
As the Perf tool only collects periodic samples, Performance Analyzer
cannot determine the exact time when a function was called or when it
returned. You can, however, see exactly when a sample was taken in the
second row of each thread. The Performance Analyzer assumes that if the same
second row of each thread. Performance Analyzer assumes that if the same
function is present at the same place in the call chain in multiple
consecutive samples, then this represents a single call to the respective
function. This is, of course, a simplification. Also, there may be other
@@ -369,7 +382,7 @@
taken for a certain function, relative to the same aspect of all samples
together. The nesting shows which functions were called by which other ones.
The \uicontrol {Visualize} button lets you choose what aspect to show in the
The \uicontrol {Visualize} button lets you select what aspect to show in the
\uicontrol {Flame Graph}.
\list
@@ -396,7 +409,7 @@
\uicontrol {Releases} modes will only show any data if samples from memory
trace points have been recorded.
\section2 Interaction between the views
\section2 Interaction between the Views
When you select a stack frame in either of the \uicontrol {Timeline},
\uicontrol {Flame Graph}, or \uicontrol {Statistics} views, information
@@ -415,7 +428,7 @@
\image qtcreator-cpu-usage-analyzer-load-perf-trace.png
The Performance Analyzer needs to know the context in which the
Performance Analyzer needs to know the context in which the
data was recorded to find the debug symbols. Therefore, you have to specify
the kit that the application was built with and the folder where the
application executable is located.
@@ -423,11 +436,11 @@
The Perf data files are generated by calling \c {perf record}. Make sure to
generate call graphs when recording data by starting Perf with the
\c {--call-graph} option. Also check that the necessary debug symbols are
available to the Performance Analyzer, either at a standard location
available to Performance Analyzer, either at a standard location
(\c /usr/lib/debug or next to the binaries), or as part of the Qt package
you are using.
The Performance Analyzer can read Perf data files generated in either frame
Performance Analyzer can read Perf data files generated in either frame
pointer or dwarf mode. However, to generate the files correctly, numerous
preconditions have to be met. All system images for the
\l{https://doc.qt.io/Boot2Qt/qtdc-supported-platforms.html}
@@ -447,11 +460,11 @@
\section1 Troubleshooting
The Performance Analyzer might fail to record data for the following reasons:
Performance Analyzer might fail to record data for the following reasons:
\list
\li Perf events may be globally disabled on your system.
The preconfigured \l Boot2Qt images come with perf events enabled.
The preconfigured \l Boot2Qt images come with Perf events enabled.
For a custom configuration you need to make sure that the file
\c {/proc/sys/kernel/perf_event_paranoid} contains a value smaller
than \c {2}. For maximum flexibility in recording traces you can
@@ -471,16 +484,16 @@
the values of the \uicontrol {Stack snapshot size} or
\uicontrol {Sample period} settings.
\li Perf may be buffering the data forever, never sending it. Add
\c {--no-delay} or \c {--no-buffering} to the
\uicontrol {Additional arguments} field.
\c {--no-delay} or \c {--no-buffering} to
\uicontrol {Additional arguments}.
\li Some versions of Perf will not start recording unless given a
certain minimum sampling frequency. Try with a
\uicontrol {Sample period} value of 1000.
certain minimum sampling frequency. Try setting
\uicontrol {Sample period} to 1000.
\li On some devices, in particular various i.MX6 Boards, the hardware
performance counters are dysfunctional and the Linux kernel may
randomly fail to record data after some time. Perf can use different
types of events to trigger samples. You can get a list of available
event types by running \c {perf list} on the device and then choose
event types by running \c {perf list} on the device and then select
the respective event types in the settings. The choice of event type
affects the performance and stability of the sampling. The
\c {cpu-clock} \c {software} event is a safe but relatively slow
@@ -489,8 +502,7 @@
reboot the device. The kernel may have disabled important parts of
the performance counters system.
\li Perf might not be installed. The way to install it depends on your
Linux distribution. For example, you might try the following
commands:
Linux distribution. For example, try the following commands:
\list
\li On Ubuntu 22.04:
@@ -506,5 +518,5 @@
The \l {Application Output} view shows some information even if the
Performance Analyzer displays error messages.
\sa {Profile function execution}
\sa {Analyze}{How To: Analyze}, {Analyzers}, {Analyzing Code}
*/

179
doc/qtcreator/src/analyze/creator-analyze.qdoc
View File

@@ -1,4 +1,4 @@
// Copyright (C) 2023 The Qt Company Ltd.
// Copyright (C) 2024 The Qt Company Ltd.
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GFDL-1.3-no-invariants-only
// **********************************************************************
@@ -17,66 +17,139 @@
To use a code analysis tool, select it in the \uicontrol {Analyze Menu} or
in the pull-down menu of the \inlineimage icons/qtcreator-debug-button.png
(\uicontrol {Start Debugging of Startup Project}) button.
When you are in the \uicontrol Debug mode, you can switch between tools by
selecting them in the menu on the debugger toolbar.
In the \uicontrol Debug mode, switch between tools by selecting them in the
menu on the debugger toolbar.
You can drag and drop the views in the \uicontrol Debug mode to new
\image qtcreator-performance-analyzer-toolbar.png {Performance Analyzer in Debug mode}
Drag the views in the \uicontrol Debug mode to new
positions on the screen. The size and position of views are saved for future
sessions. Select \uicontrol View > \uicontrol Views >
\uicontrol {Reset to Default Layout} to reset the views to their original
sizes and positions.
You can use the following code analysis tools in the \uicontrol Debug
mode:
\section1 Improving QML Performance
\QC comes with the \l{Profiling QML Applications}{QML Profiler} for
inspecting binding evaluations and signal handling when running QML code.
This is useful for identifying potential bottlenecks, especially in the
evaluation of bindings.
\section1 Finding Issues in QML Code
Run \l{JavaScript and QML Checks}{static checks} on the QML and JavaScript
code in your project to find common problems, similarly to using
\l{http://www.jslint.com}{JSLint}.
\section1 Finding Issues in C++ Code with Clang Tools
\QC comes with the following Clang tools for finding problems in C, C++, and
Objective-C source code by using static analysis:
\list
\li \l{Profiling QML Applications}{QML Profiler}
Inspect binding evaluations, signal handling, and
painting operations when running QML code. This is useful for
identifying potential bottlenecks, especially in the evaluation
of bindings.
\li \l{Checking Code Coverage}{Coco}
Analyze the way an application runs as part of a test suite, for
example, and use the results to make the tests more efficient and
complete.
\li \l{Prevent code erosion}{Axivion}
Do static code analysis and architecture analysis to detect and
eliminate unnecessary complexity of code.
\li \l{Clang Tools}
Detect problems in C, C++, and Objective-C programs by
using Clang-Tidy and Clazy.
\li \l{Detecting Memory Leaks with Heob}{Heob}
Use the Heob heap observer on Windows to detect buffer
overruns and memory leaks.
\li \l{Analyzing CPU Usage}{Performance Analyzer}
Analyze the CPU usage of embedded applications and Linux
desktop applications with the Performance Analyzer that integrates
the Linux Perf tool.
\li \l{Analyzing Code with Cppcheck}{Cppcheck}
Use the experimental Cppcheck plugin to detect undefined
behavior and dangerous coding constructs.
\li \l{Visualizing Chrome Trace Events}{Chrome Trace Format Visualizer}
Use the Chrome Trace Format (CTF) Visualizer to view
Chrome trace events. This is especially useful when viewing
large trace files that are difficult to visualize using the
built-in trace-viewer (\c{chrome://tracing}).
\li \l{https://clang.llvm.org/extra/clang-tidy/}{Clang-Tidy}, which
has diagnostics and fixes for typical programming errors,
such as style violations or interface misuse.
\li \l{https://github.com/KDE/clazy/blob/master/README.md}{Clazy}, which
helps Clang understand Qt semantics. It displays Qt-related compiler
warnings, ranging from unnecessary memory allocation to misuse of
API and has refactoring actions for fixing some of the issues.
\endlist
\sa {Detect memory leaks with Memcheck}, {Profile function execution}
\section1 Finding Issues in C++ Code with Cppcheck
Install the \l{http://cppcheck.sourceforge.net/}{Cppcheck} static analysis
tool to detect undefined behavior and dangerous coding constructs in
C++ code. Cppcheck analyzes the source code without actually running the
application.
\section1 Checking Code Coverage
Install the \l{https://doc.qt.io/coco/}{Coco} code coverage tool chain for
Tcl, QML, C# and C/C++ programs on \macOS, Linux, or Windows to analyze the
way an application runs as part of a test suite, for example. Use the
results to make the tests more efficient and complete.
You can:
\list
\li Find untested code sections.
\li Find redundant tests which can then be eliminated. Coco can
identify portions of the source code that are covered by a test. It
can detect whether a new test covers lines in the source code that
the existing tests do not cover.
\li Find dead code by displaying code that is never executed.
\li Calculate the optimum test execution order so as to maximize
test coverage for each run. This is particularly useful for manual
testing.
\li Analyze two separate versions of an application and compare the
differences. This makes it possible to see which tests are affected
by source code modifications and also to get some measure of the
test coverage of a patch or hot fix.
\li Measure the execution time of applications and tests.
\endlist
\section1 Preventing Code Erosion
Install \l{https://www.axivion.com/en/products/axivion-suite/}{Axivion Suite}
to protect software from erosion. With static code analysis,
architecture analysis, and code-smells-detection, you can:
\list
\li Check the source code for potential runtime errors.
\li Use metrics to generate quantitative information about the
internal quality of the source code.
\li Run style checks to achieve compliance with coding guidelines.
\li Detect both duplicates and similar pieces of code in the source code.
\li Recognize cyclical dependencies at different levels.
\li Detect unreachable code.
\endlist
\section1 Profiling with Valgrind Tools
Install Memcheck and Callgrind from \l{Valgrind's Tool Suite} to detect
memory leaks and profile function execution.
You can run the Valgrind tools either \e locally on the development host or
\e remotely on another host. You can use them to analyze both applications
for which you set up a project in \QC and applications for which you do not
have a project.
Valgrind tools are supported locally only on Linux and \macos. However,
according to Valgrind.org, support on \macos 10.8 and 10.9 is experimental and
mostly broken. You can run the tools on a remote Linux machine or device
from any development host.
To run the Valgrind tools to analyze an application for which you have a
project, open the project in \QC and select the kit to run the project. The
kit specifies whether the Valgrind tools are run locally or remotely.
For more information about analyzing applications for which you do not have
a project, see \l{Run Valgrind tools on external applications}.
To set preferences for the Valgrind tools, select \preferences >
\uicontrol Analyzer. You can override the general
settings for each project in the \uicontrol {Run Settings} for the project.
\section1 Detecting Memory Leaks with Heob
On Windows, install the \l{https://github.com/ssbssa/heob}{Heob}
heap observer to detect buffer overruns and memory leaks.
\section1 Analyzing CPU Usage
On Linux, use Perf to analyze the CPU and memory usage of an application
on Linux desktop and embedded devices.
\l{Performance Analyzer} uses the Perf tool bundled with the Linux kernel to
take periodic snapshots of the call chain of an application and visualizes
them in a timeline view or as a flame graph.
\section1 Visualizing Chrome Trace Events
Use the \l{Chrome Trace Format Visualizer} to view Chrome trace events. This
is especially useful when viewing large trace files that are difficult to
visualize using the built-in trace-viewer (\c{chrome://tracing}).
\sa {Analyze}{How To: Analyze}, {Analyzers}
*/

19
doc/qtcreator/src/analyze/creator-axivion.qdoc
View File

@@ -9,20 +9,6 @@
\title Prevent code erosion
\l{https://www.axivion.com/en/products/axivion-suite/}{Axivion Suite} is
a tool suite for protecting software from erosion. With static code analysis,
architecture analysis, and code-smells-detection, you can:
\list
\li Check the source code for potential runtime errors.
\li Use metrics to generate quantitative information about the
internal quality of the source code.
\li Run style checks to achieve compliance with coding guidelines.
\li Detect both duplicates and similar pieces of code in the source code.
\li Recognize cyclical dependencies at different levels.
\li Detect unreachable code.
\endlist
Connect to an Axivion dashboard server from \QC to view results of code
analysis.
@@ -132,8 +118,9 @@
select the link in the details or in the \uicontrol {Right Path}
or \uicontrol {Target Path} column.
\sa {Enable and disable plugins}, {Link projects to Axivion dashboards},
{Axivion}
\sa {Enable and disable plugins}, {Analyze}{How To: Analyze},
{Link projects to Axivion dashboards}, {Analyzers}, {Axivion},
{Analyzing Code}
*/
/*!

19
doc/qtcreator/src/analyze/creator-clang-static-analyzer.qdoc
View File

@@ -15,22 +15,6 @@
\title Analyze code with Clang-Tidy and Clazy
\QC comes with the following Clang tools for finding problems in C, C++, and
Objective-C source code by using static analysis:
\list
\li \l{https://clang.llvm.org/extra/clang-tidy/}{Clang-Tidy}, which
has diagnostics and fixes for typical programming errors,
such as style violations or interface misuse.
\li \l{https://github.com/KDE/clazy/blob/master/README.md}{Clazy}, which
helps Clang understand Qt semantics. It displays Qt related compiler
warnings, ranging from unnecessary memory allocation to misuse of
API and has refactoring actions for fixing some of the issues.
\endlist
\note The Clang static analyzer checks are a part of Clang-Tidy. To use
the checks, you must create a custom configuration for the Clang tools and
enable them for Clang-Tidy.
@@ -107,7 +91,8 @@
using the \c {-export fixes} option.
\sa {Check code syntax}, {Configure Clang Diagnostics},
{Specify Clang tools settings}, {Clang Tools}
{Analyze}{How To: Analyze}, {Specify Clang tools settings}, {Analyzers},
{Clang Tools}
*/
/*!

61
doc/qtcreator/src/analyze/creator-coco.qdoc
View File

@@ -2,72 +2,46 @@
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GFDL-1.3-no-invariants-only
/*!
\previouspage creator-qml-performance-monitor.html
\page creator-coco.html
\nextpage creator-axivion.html
\previouspage creator-how-tos.html
\title Checking Code Coverage
\ingroup creator-how-to-analyze
\l{https://doc.qt.io/coco/}{Coco} is a complete code coverage tool chain for
Tcl, QML, C# and C/C++ programs, which runs on \macOS, Linux, and Windows.
\title Check code coverage
Coco analyzes the way an application runs, as part of a test suite,
for example. The results enable you to make the tests more efficient and
complete.
You can:
\list
\li Find untested code sections.
\li Find redundant tests which can then be eliminated. Coco can
identify portions of the source code that are covered by a test. It
can detect whether a new test covers lines in the source code that
the existing tests do not cover.
\li Find dead code by displaying code that is never executed.
\li Calculate the optimum test execution order so as to maximize
test coverage for each run. This is particularly useful for manual
testing.
\li Analyze two separate versions of an application and compare the
differences. This makes it possible to see which tests are affected
by source code modifications and also to get some measure of the
test coverage of a patch or hot fix.
\li Measure the execution time of applications and tests.
\endlist
The experimental Coco plugin integrates Coco CoverageBrowser into \QC.
It enables you to analyze the test coverage by loading an instrumentation
database (a .csmes file), which was generated by Coco CoverageScanner.
It is currently supported only on Windows, with Coco version 6.0,
or later.
With Coco CoverageBrowser, you can analyze the test coverage by loading an
instrumentation database (a .csmes file), which was generated by Coco
CoverageScanner. The experimental Coco plugin is currently supported only on
Windows, with Coco version 6.0, or later.
To use the plugin, you must download and install Coco.
\note Enable the Coco plugin to use it.
\section1 Configuring Coco
\section1 Configure Coco
\list 1
\li Select \uicontrol Analyze > \uicontrol {Squish Coco}.
\image qtcreator-coco.png "Coco CoverageBrowser and CSMes file"
\li Go to \uicontrol Analyze > \uicontrol {Squish Coco}.
\image qtcreator-coco.png {Coco CoverageBrowser and CSMes file}
\li In \uicontrol {CoverageBrowser}, enter the path to the Coco
coverage browser to use for analyzing a .csmes file.
\li In \uicontrol CSMes, select the instrumentation database to load.
\li Select \uicontrol Open to start CoverageBrowser.
\li In CoverageBrowser, select \uicontrol File >
\li In CoverageBrowser, go to \uicontrol File >
\uicontrol {Load Execution Report} and select the .csexe for the
coverage scan.
\image coco-coveragebrowser-load-execution-report.png "Load Execution Report dialog"
\li If you want to reuse the execution report, deselect the
\uicontrol {Delete execution report after loading} check box.
\image coco-coveragebrowser-load-execution-report.png {Load Execution Report dialog}
\li To keep the execution report, clear
\uicontrol {Delete execution report after loading}.
\endlist
Open the analyzed files in \QC. The results of the analysis are displayed
Open the analyzed files in \QC. You can see the results of the analysis
after the code in \uicontrol Edit mode. You can change the fonts and colors
used for different types of results.
\section1 Changing Fonts and Colors
To change the default fonts and colors, select \preferences >
To change the default fonts and colors, go to \preferences >
\uicontrol {Text Editor} > \uicontrol {Font & Colors}.
Create your own color scheme and select new fonts and colors for the
following results:
@@ -85,5 +59,6 @@
\li Implicit Manual Coverage Validation
\endlist
\sa {Enable and disable plugins}, {Font & Colors}
\sa {Enable and disable plugins}, {Analyze}{How To: Analyze}, {Analyzers},
{Font & Colors}, {Analyzing Code}
*/

62
doc/qtcreator/src/analyze/creator-cppcheck.qdoc
View File

@@ -1,58 +1,51 @@
// Copyright (C) 2020 The Qt Company Ltd.
// Copyright (C) 2024 The Qt Company Ltd.
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GFDL-1.3-no-invariants-only
/*!
\previouspage creator-cpu-usage-analyzer.html
\page creator-cppcheck.html
\nextpage creator-ctf-visualizer.html
\previouspage creator-how-tos.html
\title Analyzing Code with Cppcheck
\ingroup creator-how-to-analyze
\l{http://cppcheck.sourceforge.net/}{Cppcheck} is a static analysis tool
that detects errors in C++ code. Static analysis is performed on the source
code without actually executing the application.
\title Detect errors in C++ code with Cppcheck
The experimental Cppcheck Diagnostics plugin integrates diagnostics
that are generated by the Cppcheck tool into the C++ editor.
\note Enable the Cppcheck plugin to use it.
Enable the experimental Cppcheck plugin to view diagnostics that are
generated by the Cppcheck tool in the C++ editor.
Cppcheck is automatically run on open files. To select the files to
check in the currently active project, select \uicontrol Analyze >
check in the currently active project, go to \uicontrol Analyze >
\uicontrol Cppcheck.
\section1 Running Cppcheck on Selected Files
\section1 Analyze selected files
\list 1
\li Select \uicontrol Analyze > \uicontrol Cppcheck.
\image qtcreator-cppcheck-run-configuration.png "Cppcheck run configuration"
\li In the \uicontrol Binary field, enter the path to the Cppcheck
executable file.
\li In the \uicontrol Checks group, select the checks to perform.
\li Go to \uicontrol Analyze > \uicontrol Cppcheck.
\image qtcreator-cppcheck-run-configuration.png {Cppcheck run configuration}
\li In uicontrol Binary, enter the path to the Cppcheck executable file.
\li In \uicontrol Checks, select the checks to perform.
\note By default, Cppcheck uses multiple threads to perform checks.
Selecting the \uicontrol {Unused functions} option disables the
default behavior.
\li In the \uicontrol {Custom arguments} field, enter additional
Select \uicontrol {Unused functions} to turn off the default
behavior.
\li In \uicontrol {Custom arguments}, enter additional
arguments for running Cppcheck. The arguments might be shadowed
by automatically generated ones. To avoid possible conflicts in
configuration, select the \uicontrol {Show raw output} check box
to see the final arguments.
\li In the \uicontrol {Ignored file patterns} field, enter a filter
configuration, select \uicontrol {Show raw output} and check the
final arguments.
\li In \uicontrol {Ignored file patterns}, enter a filter
for ignoring files that match the pattern (wildcard). You can enter
multiple patterns separated by commas. Even though Cppcheck is not
run on files that match the patterns, they might be
implicitly checked if other files include them.
\li Select the \uicontrol {Inconclusive errors} check box to also
mark possible false positives.
\li Select the \uicontrol {Check all define combinations} check box to
check all define combinations. Enabling this option can significantly
\li Select \uicontrol {Inconclusive errors} to also mark possible false
positives.
\li Select \uicontrol {Check all define combinations} to
check all define combinations. This can significantly
slow down analysis, but might help to find more issues.
\li Select the \uicontrol {Add include paths} check box to pass the
current project's include paths to Cppcheck. Enabling this option
\li Select \uicontrol {Add include paths} to pass the
current project's include paths to Cppcheck. This
slows down checks on big projects, but can help Cppcheck to find
missing includes.
\li Select the \uicontrol {Calculate additional arguments} check box to
\li Select \uicontrol {Calculate additional arguments} to
calculate additional arguments based on current project's settings
(such as the language used and standard version) and pass them to
Cppcheck.
@@ -64,8 +57,9 @@
marks or annotations.
To specify the settings above for the automatically run checks,
select \preferences > \uicontrol Analyzer
go to \preferences > \uicontrol Analyzer
> \uicontrol Cppcheck.
\sa {Enable and disable plugins}
\sa {Enable and disable plugins}, {Analyze}{How To: Analyze},
{Analyzing Code}, {Analyzers}
*/

11
doc/qtcreator/src/analyze/creator-ctf-visualizer.qdoc
View File

@@ -8,11 +8,14 @@
// **********************************************************************
/*!
\previouspage creator-cppcheck.html
\page creator-ctf-visualizer.html
\nextpage creator-autotest.html
\previouspage creator-reference.html
\title Visualizing Chrome Trace Events
\ingroup creator-reference-analyzer
\title Chrome Trace Format Visualizer
\brief Visualize Chrome trace events generated in Chrome Trace Format (CTF).
You can use \e {full stack tracing} to trace from the top level QML or
JavaScript down to the C++ and all the way to the kernel space. This
@@ -218,4 +221,6 @@
\code
ctf2ctf -o trace.json path/to/lttng trace/
\endcode
\sa {Analyze}{How To: Analyze}, {Analyzers}, {Analyzing Code}
*/

82
doc/qtcreator/src/analyze/creator-heob.qdoc
View File

@@ -1,4 +1,4 @@
// Copyright (C) 2020 The Qt Company Ltd.
// Copyright (C) 2024 The Qt Company Ltd.
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GFDL-1.3-no-invariants-only
// **********************************************************************
@@ -8,17 +8,15 @@
// **********************************************************************
/*!
\page creator-how-to-use-heob.html
\previouspage creator-clang-tools.html
\page creator-heob.html
\nextpage creator-cpu-usage-analyzer.html
\title Detecting Memory Leaks with Heob
\ingroup creator-how-to-analyze
\QC integrates the \l{https://github.com/ssbssa/heob}{Heob} heap observer
for detecting buffer overruns and memory leaks. You must download and
install Heob to run it from \QC.
\title Detect memory leaks with Heob
\image qtcreator-heob-settings.png
On Windows, use the Heob heap observer to detect buffer overruns and memory
leaks.
To run Heob on the currently open project:
@@ -26,35 +24,48 @@
\li Select \uicontrol Analyze > \uicontrol Heob.
\image qtcreator-heob-settings.png {Heob settings}
\li Select the Heob settings profile to use, or select \uicontrol New
to create a new profile.
\li In the \uicontrol {Heob path} field, enter the path to the Heob
\li In \uicontrol {Heob path}, enter the path to the Heob
executable.
\li Specify additional settings for running the checks. For more
information about the available options, see
\l{Specifying Heob Settings}.
\li Specify \l{Heob}{settings} for running the checks.
\li Select \uicontrol OK to run Heob.
\endlist
\QC runs the application, and then it runs Heob in a console window.
\QC runs the application, and then it runs Heob in a terminal.
\image qtcreator-heob.png
\image qtcreator-heob-in-terminal.webp {Heob running in a terminal}
Heob raises an access violation on buffer overruns and records stack traces
of the offending instruction and buffer allocation. The results are
displayed when Heob exits normally.
of the offending instruction and buffer allocation. You can see the results
in the \uicontrol Memcheck view after Heob exits normally.
\image qtcreator-heob-output.png
\image qtcreator-heob-output.png {Results from Heob in the Memcheck view}
\section1 Specifying Heob Settings
\sa {Analyze}{How To: Analyze}, {Analyzers}, {Heob}, {Analyzing Code}
*/
To specify settings for Heob, select \uicontrol Analyze > \uicontrol Heob.
/*!
\page creator-heob.html
\previouspage creator-reference.html
In the \uicontrol {Extra arguments} field, enter additional arguments for
\ingroup creator-reference-analyzer
\title Heob
\brief Detect memory leaks with Heob.
To specify settings for Heob, go to \uicontrol Analyze > \uicontrol Heob.
\image qtcreator-heob-settings.png {Heob settings}
In \uicontrol {Extra arguments}, enter additional arguments for
running Heob. To list the available arguments in the Heob console, enter
\c -H in this field and press \key Enter.
@@ -63,19 +74,19 @@
leaks visually in the file and the \c -L1024 option to record leak contents
up to 1024 bytes in the file. For example, \c {-oleaks.html -g2 -L1024}
To save the settings profile, select \uicontrol Save.
To save your changes as default settings, select
\inlineimage icons/savefile.png.
To remove a customized settings profile, select the profile, and then
select \uicontrol Delete.
The following sections describe the available options in more detail.
\section2 Recording Results
\section1 Recording Results
The results of the checks are displayed in the \uicontrol Memcheck view and
recorded in a file. You can specify the file name in the
\uicontrol {XML output file} field. Heob creates the file in the project
directory.
recorded in a file. Specify the file name in \uicontrol {XML output file}.
Heob creates the file in the project directory.
You can use the process identifier (PID) as a variable in the file name.
For example, \c leaks-%p.xml. This injects Heob into the child processes,
@@ -87,9 +98,9 @@
If you use variables, \QC cannot open the file automatically, but you can
open it from the project directory.
\section2 Handling Exceptions
\section1 Handling Exceptions
In the \uicontrol {Handle exceptions} list, select \uicontrol Off to use the
In \uicontrol {Handle exceptions}, select \uicontrol Off to use the
standard exception handler and have the debugger automatically attached if
the application crashes. This works only if you register \QC is as a
post-mortem debugger by selecting \preferences >
@@ -105,7 +116,7 @@
crash is displayed. Therefore, this option is mostly useful when using Heob
on the console or running it for child processes, as well.
\section2 Raising Exceptions on Errors
\section1 Raising Exceptions on Errors
Select the \uicontrol {Raise breakpoint exception on error} check
box to display errors when the application runs.
@@ -119,9 +130,9 @@
This is mostly useful when used with the \uicontrol {Run with debugger}
option, which runs Heob under the debugger.
\section2 Protecting Pages
\section1 Protecting Pages
In the \uicontrol {Page protection} list, select \uicontrol Off to use
In \uicontrol {Page protection}, select \uicontrol Off to use
standard memory allocation functions and enable only memory leak detection.
Select \uicontrol After to place a protected page at the end of each
@@ -135,9 +146,9 @@
useful for \e use-after-free and \e double-free detection. However, the
available memory address space can run out fast for 32-bit programs.
\section2 Handling Leak Data
\section1 Handling Leak Data
In the \uicontrol {Leak details} list, determine how to handle the
In \uicontrol {Leak details}, determine how to handle the
collected leak data when the process exits. Selecting \uicontrol None means
that no leak data is collected. If you activate leak type detection, Heob
might need more time to collect the data when the process exits.
@@ -163,10 +174,10 @@
block. Select \uicontrol {Detect Leak Types (Show Reachable)} to also
record the reachable blocks in the results file.
In the \uicontrol {Minimum leak size} list, select the size of
In \uicontrol {Minimum leak size}, select the size of
leaks to detect in bytes.
In the \uicontrol {Control leak recording} list, select \uicontrol Off to
In \uicontrol {Control leak recording}, select \uicontrol Off to
record all leaks. You cannot change leak recording while it is running.
To start Heob without starting leak recording, select
@@ -177,4 +188,7 @@
To start leak recording when Heob starts and still have the option to
control the recording, select \uicontrol {On (Start Enabled)}.
\sa {Detect memory leaks with Heob}, {Analyze}{How To: Analyze}, {Analyzers},
{Analyzing Code}
*/

6
doc/qtcreator/src/analyze/creator-valgrind.qdoc
View File

@@ -81,10 +81,10 @@
For more information about using Memcheck, see
\l{Interpreting Memcheck's Output} in the Valgrind documentation.
\sa {Profile function execution},
\sa {Analyze}{How To: Analyze}, {Profile function execution},
{Run Valgrind tools on external applications},
{Specify Valgrind settings for a project}, {Valgrind Callgrind},
{Valgrind Memcheck}
{Specify Valgrind settings for a project}, {Analyzers}, {Valgrind Callgrind},
{Valgrind Memcheck}, {Analyzing Code}
*/
/*!

2
doc/qtcreator/src/cmake/creator-how-to-profile-cmake-code.qdoc
View File

@@ -19,5 +19,5 @@
\image qtcreator-cmake-profiler.webp {CMake profiling information in Chrome Trace Format Visualizer}
\sa {CMake}, {Visualizing Chrome Trace Events}
\sa {CMake}, {Chrome Trace Format Visualizer}
*/

14
doc/qtcreator/src/editors/creator-code-syntax.qdoc
View File

@@ -9,7 +9,7 @@
\previouspage creator-how-tos.html
\endif
\ingroup creator-how-to-edit
\ingroup creator-how-to-analyze
\ingroup studio-how-to-code
\title Check code syntax
@@ -79,11 +79,11 @@
If you hide the annotations, you can move the mouse pointer over an icon to
view them.
\if defined(qtcreator)
\sa {Analyze code with Clang-Tidy and Clazy}
\endif
\sa {JavaScript and QML Checks}
\if defined(qtcreator)
\sa {Analyze}{How To: Analyze}, {Analyzers}, {Analyzing Code}
\endif
*/
/*!
@@ -766,6 +766,10 @@
\uicontrol {Reset Code Model}.
\sa {Check code syntax}, {Using QML Modules with Plugins}
\if defined(qtcreator)
\sa {Analyzing Code}
\endif
*/
/*!

10
doc/qtcreator/src/overview/creator-only/creator-overview.qdoc
View File

@@ -244,18 +244,18 @@
For more information, see \l{Debugging}.
\section1 Analyzing Source Code
\section1 Finding Issues in Source Code
Devices have limited memory and CPU power, so you should use them carefully.
\QC integrates code analysis tools for detecting memory leaks, profiling
function execution, analyzing CPU use, and eliminating unnecessary complexity
of code. Other tools provide code coverage and visualize trace events.
Install and configure the tools on your system to use them from \QC.
However, the QML Profiler is installed as part of \QC for profiling
Qt Quick applications.
Some tools, such as the QML Profiler and the Clang Tools, are installed with
\QC. Install and configure the other supported tools on the computer to use
them from \QC.
For more information, see \l{Analyzing Code}.
For more information, see \l{Analyzing Code} and \l{Analyze}{How To: Analyze}.
\section1 Running Tests

2
doc/qtcreator/src/projects/creator-only/creator-build-settings-qmake.qdoc
View File

@@ -51,7 +51,7 @@
If debug info is being generated, you can have it placed into separate
files, rather than embedded into the binary, by selecting
\uicontrol Enable in the \uicontrol {Separate debug info} field. For
more information, see \l{Using the Performance Analyzer}. To use default
more information, see \l{Analyze CPU usage}. To use default
settings, select \uicontrol {Leave at Default}.
\section1 Compiling QML

2
doc/qtcreator/src/projects/creator-only/creator-projects-settings-build-qbs.qdoc
View File

@@ -30,7 +30,7 @@
If debug info is being generated, you can have it placed into separate
files, rather than embedded into the binary, by selecting
\uicontrol Enable in the \uicontrol {Separate debug info} field. For
more information, see \l{Using the Performance Analyzer}. To use default
more information, see \l{Analyze CPU usage}. To use default
settings, select \uicontrol {Leave at Default}.
For more information about the QML debugging options, see

10
doc/qtcreator/src/qtcreator-toc.qdoc
View File

@@ -73,14 +73,6 @@
\li \l{Troubleshooting Debugger}
\endlist
\li \l{Analyzing Code}
\list
\li \l{Profiling QML Applications}
\li \l{Checking Code Coverage}
\li \l{Detecting Memory Leaks with Heob}
\li \l{Analyzing CPU Usage}
\li \l{Analyzing Code with Cppcheck}
\li \l{Visualizing Chrome Trace Events}
\endlist
\endlist
\li \l{Tutorials}
\generatelist creator-tutorials
@@ -136,6 +128,8 @@
\li \l{Reference}
\generatelist creator-reference
\list
\li Analyzers
\generatelist creator-reference-analyzer
\li Build Systems
\generatelist creator-reference-build-systems
\list

9
doc/qtcreator/src/qtquick/qtquick-profiler.qdoc
View File

@@ -13,12 +13,15 @@
\previouspage creator-qml-debugging-example.html
\nextpage studio-advanced.html
\else
\previouspage creator-analyze-mode.html
\nextpage creator-coco.html
\previouspage creator-reference.html
\endif
\ingroup creator-reference-analyzer
\title Profiling QML Applications
\brief Improve the performance of QML applications.
You can use the QML Profiler to find causes for typical performance problems
in your applications, such as slowness and unresponsive, stuttering user
interfaces. Typical causes include executing too much JavaScript in too few
@@ -54,7 +57,7 @@
You can use \e {full stack tracing} to trace from the top level QML or
JavaScript down to the C++ and all the way to the kernel space. You can
view the collected data in the \l{Visualizing Chrome Trace Events}
view the collected data in the \l{Chrome Trace Format Visualizer}
{Chrome Trace Format Viewer}.
\endif