Lines Matching +full:test +full:- +full:docs
7 computation of summary metrics, annotating the trace with user-friendly
10 
14 The [quickstart](/docs/quickstart/trace-analysis.md) provides a quick overview
19 Events in a trace are optimized for fast, low-overhead recording. Therefore
30 * Execution of SQL queries on a custom, in-memory, columnar database backed by
34 * Annotating events in the trace with user-friendly descriptions, providing
45 * [Ninja](https://ninja-build.org/) logs (the build system)
49 * [trace_processor](/docs/analysis/trace-processor.md), a standalone binary
71 
82 
88 * RSS memory events - both from the kernel and polled from /proc/stats
106 
129 ## Object-oriented tables
137 To solve this problem in object-oriented languages, a `Track` class could be
142 
144 In trace processor, this "object-oriented" approach is replicated by having
149 NOTE: [The appendix below](#appendix-table-inheritance) gives the exact rules
155 
157 NOTE: For an up-to-date of how tables currently inherit from each other as well
159 the [SQL tables](/docs/analysis/sql-tables.autogen) reference page.
195 | :--------- | ------------------ | --------------------- | -------------------------- |
298 
301 -- Get all the scheduling slices
306 -- Get all the cpu frequency slices
310 lead(ts) OVER (PARTITION BY track_id ORDER BY ts) - ts as dur,
317 -- Create the span joined table which combines cpu frequency with
318 -- scheduling slices.
322 -- This span joined table can be queried as normal and has the columns from both
323 -- tables.
343 -- Left table partitioned + right table unpartitioned.
347 -- Both tables unpartitioned.
355 non-empty. This approach was decided as being the most natural
360 [slice table's id column](/docs/analysis/sql-tables.autogen#slice) and computes
366 [slice table](/docs/analysis/sql-tables.autogen#slice)
385 [slice table's stack_id column](/docs/analysis/sql-tables.autogen#slice) and
388 [ancestor_slice](/docs/analysis/trace-processor#ancestor-slice).
391 [slice table](/docs/analysis/sql-tables.autogen#slice)
411 [slice table's id column](/docs/analysis/sql-tables.autogen#slice) and
417 [slice table](/docs/analysis/sql-tables.autogen#slice)
439 [slice table's stack_id column](/docs/analysis/sql-tables.autogen#slice) and
442 [descendant_slice](/docs/analysis/trace-processor#descendant-slice).
445 [slice table](/docs/analysis/sql-tables.autogen#slice)
467 [slice table's id column](/docs/analysis/sql-tables.autogen#slice) and collect
468 all entries of [flow table](/docs/analysis/sql-tables.autogen#flow), that are
471 `DIRECTLY_CONNECTED_FLOW(start_slice_id)` - contains all entries of
472 [flow table](/docs/analysis/sql-tables.autogen#flow) that are present in any
473 chain of kind: `flow[0] -> flow[1] -> ... -> flow[n]`, where
481 `FOLLOWING_FLOW(start_slice_id)` - contains all flows which can be reached from
484 all entries of [flow table](/docs/analysis/sql-tables.autogen#flow) that are
485 present in any chain of kind: `flow[0] -> flow[1] -> ... -> flow[n]`, where
490 `PRECEDING_FLOW(start_slice_id)` - contains all flows which can be reached from
493 all entries of [flow table](/docs/analysis/sql-tables.autogen#flow) that are
494 present in any chain of kind: `flow[n] -> flow[n-1] -> ... -> flow[0]`, where
500 --number of following flows for each slice
507 [here](/docs/contributing/common-tasks.md#new-metric).
510 documented on its own [page](/docs/analysis/metrics.md).
515 checklist [here](/docs/contributing/common-tasks.md#new-annotation).
521 This is useful as often the data in the trace is very low-level. While low
532 [metrics subsystem](/docs/analysis/metrics.md); often SQL-based metrics need to
533 create higher-level abstractions from raw events as intermediate artifacts.
544 is documented on a [separate page](/docs/analysis/trace-processor-python.md).
549 1. Unit tests of low-level building blocks
563 use unit testing for the low-level building blocks on which the rest of
570 Each diff test takes as input a) a trace file b) a query file *or* a metric
575 All diff tests are organized under [test/trace_processor](/test/trace_processor)
579 To add a new test its enough to add a new method starting with `test_` in suitable
599 to do this is to run `tools/ninja -C <out directory>` both initially and on
609 parsed correctly and the corresponding built-in tables are populated.
618 _Answer_: Add the test to the `stdlib/foo/bar_tests.py` file.
620 __Scenario__: A new event is being parsed, the focus of the test is to ensure
623 _Answer_: Add the test in one of the `parser` subdirectories. Prefer adding a
624 test to an existing related directory (i.e. `sched`, `power`) if one exists.
626 __Scenario__: A new metric is being added and the focus of the test is to
629 _Answer_: Add the test in one of the `metrics` subdirectories. Prefer adding a
630 test to an existing related directory if one exists. Also consider adding the
633 __Scenario__: A new dynamic table is being added and the focus of the test is to
636 _Answer_: Add the test to the `stdlib/dynamic_tables` folder
638 __Scenario__: The interals of trace processor are being modified and the test
640 built-in tables.
642 _Answer_: Add the test to the `parser/core_tables` folder.