GPROFNG-DISPLAY-TEXT(1)

πŸ’… GPROFNG-DISPLAY-TEXT πŸ’…

so like, the manual name is gprofng-display-text and bestie, it's giving "performance data, but make it plain text". no cap. πŸŽ€


🌸 NAME 🌸

gprofng-display-text β€” Display the performance data in plain text format. that's it, that's the whole job. plain text, all tea, no graphics. ✨


πŸ¦‹ SYNOPSIS πŸ¦‹

gprofng display text [option(s)] [commands] [-script script-file]
experiment(s)

πŸ’œ DESCRIPTION πŸ’œ

okay so basically this prints a plain text version of all the various displays that gprofng supports. lowkey iconic of it.

the input is one or more experiment directories. and through commands you, the user, control the output. you're the main character here. πŸ‘‘

there's a rich set of commands to control how the data gets displayed. the NOTES section down below lists the most common ones, and the gprofng user guide lists literally all the commands supported. so if you're looking for a deep cut, that's where it lives.

commands you put on the command line need to be prepended with the dash (-) symbol. like, mandatory. don't skip it. 😭

so in this example, a function overview gets shown, followed by the source code listing of function my-func, annotated with the performance metrics that were recorded during the data collection and stored in experiment directory my-exp.er:

$ gprofng display text -functions -source my-func my-exp.er

instead of β€” or in addition to β€” specifying these commands on the command line, commands may also be included in a file called the script-file. options bestie, we love options. 🫢

note that the commands are processed and interpreted from left to right, so the order matters. this is not a vibe where you can shuffle things. 🚨

and if this tool is invoked without options, commands, or a script file, it starts in interpreter mode. you can then issue the commands interactively, like a little conversation with your computer. πŸ’¬ the session is terminated with the exit command in the interpreter. bye bestie! πŸ‘‹


✨ OPTIONS ✨

  • --version β€” Print the version number and exit. short, sweet, slayed.
  • --help β€” Print usage information and exit. your emergency contact when you're lost. πŸ™ˆ
  • -script script-file β€” Execute the commands stored in the script file. this feature may be combined with commands specified at the command line, so you can have both at once like a legend. πŸ”₯

πŸ”₯ NOTES πŸ”₯

Many commands are supported. below, the more common ones are listed in mostly alphabetical order, because sometimes it is more logical to swap the order of two entries. the author is chaotic but correct. πŸ’€

there are many more commands than these. those are documented in the user guide. iykyk.

πŸ’– callers-callees

in a callers-callees panel, it shows which function(s) call the target function (the callers) and what functions it is calling (the callees). this command prints the callers-callees panel for each of the functions, in the order specified by the function sort metric. friendship network but for code. πŸ«‚

πŸ’– calltree

Display the dynamic call graph from the experiment, showing the hierarchical metrics at each level. it's the family tree but everyone's carrying performance numbers. 🌳

πŸ’– compare {on | off | delta | ratio}

by default, the results for multiple experiments are aggregated. this command changes that, so you can compare experiments for certain views (e.g. the function view). ✨ the first experiment specified is defined to be the reference. ✨ the following options are supported:

  • on β€” For each experiment specified on the command line, print the values for the metrics that have been activated for the experiment.
  • off β€” Disable the comparison of experiments. This is the default. (the chill, go-with-the-flow option πŸ“)
  • delta β€” Print the values for the reference experiment. The results for the other experiments are shown as a delta relative to the reference (current-reference). subtraction era 😀
  • ratio β€” Print the values for the reference experiment. The results for the other experiments are shown as a ratio relative to the reference (current/reference). division era βž—

πŸ’– disasm function-name

List the source code and instructions for the function specified. the instructions are annotated with the metrics used. assembly reveal, but make it educational. 🧚

πŸ’– fsingle function-name [n]

Write a summary panel for the specified function. the optional parameter n is needed for those cases where several functions have the same name β€” yes, name collisions are real, we've all been there. 😭

πŸ’– fsummary

Write a summary panel for each function in the function list. all of them. every single one. we're being thorough. πŸ’…

πŸ’– functions

Display a list of all functions executed. for each function the used metrics (e.g. the CPU time) are shown. the classic, the moment, the legend. πŸ‘‘

Shows several operational characteristics of the experiment(s) specified on the command line. the "who is this and what are they on" panel. 🌈

πŸ’– limit n

Limit the output to n lines. boundaries, bestie. we love them. βœ‹

πŸ’– lines

Write a list of source lines and their metrics, ordered by the current sort metric. line by line, number by number. ⭐

πŸ’– metric_list

Display the currently selected metrics in the function view and a list of all the metrics available for the target experiment(s). two for one, ate that. πŸŽ€

πŸ’– metrics metric-spec

Define the metrics to be displayed in the function and callers-callees overviews.

the metric-spec can either be:

  • the keyword default, to restore the default metrics selection, or
  • a colon separated list with metrics.

a special metric is hwc. it automatically expands to the active set of hardware event counters used in the experiment(s). so magic, so ✨.

if both instructions and clock cycles have been measured, the CPI and IPC metrics can be used to see the Clockcycles Per Instruction and Instructions Per Clockcyle values, respectively. (yes, the acronym game is strong here.)

the gprofng user guide has more details on how to define metrics. πŸ“š

πŸ’– name {short | long | mangled}[:{soname | nosoname}]

Specify whether to use the short, long, or mangled form of function names. optionally, the load object that the function is part of can be included in the output by adding the soname keyword. it can also be ommitted (nosoname), which is the default.

whether there is an actual difference between these types of names depends on the language. 🀷

Note that there should be no (white)space to the left and right of the colon (:). not a single space. none. zero. πŸ™…

this option should not be confused with the keyword name in a metric definition, which is used to specify that the names of functions should be shown in the function overview. two different names, do not mix them up, that's the whole warning bestie. 😭

πŸ’– overview

Shows a summary of the recorded performance data for the experiment(s) specified on the command line. the tl;dr of your whole run. πŸ’…

πŸ’– pcs

Write a list of program counters (PCs) and their metrics, ordered by the current sort metric. ngl this one's for the real ones. 🧠

πŸ’– sort metric-spec

Sort the function list on the metric-spec given.

  • the data can be sorted in reverse order by prepending the metric definition with a minus (-) sign.

for example sort -e.totalcpu.

teeny aside for the texinfo girlies: this bit is indexed as @IndexSubentry{Sort, Reverse order} 🌸
  • a default metric for the sort operation has been defined, and since this is a persistent command, this default can be restored with "default" as the key β€” i.e. sort default.
and this one is indexed as @IndexSubentry{Sort, Reset to default} ✨

πŸ’– source function-name

List the source code for the function specified, annotated with the metrics used. reading the source, but with receipts. πŸ“–

πŸ’– viewmode {user | expert | machine}

this command is only relevant for Java programs. for all other languages supported, the viewmode setting has no effect. πŸ«₯

the following options are supported:

  • user β€” Show the Java call stacks for Java threads, but do not show housekeeping threads. the function view includes a function called <JVM-System>. this represents the aggregated time from non-Java threads. in case the JVM software does not report a Java call stack, time is reported against the function <no Java callstack recorded>.
  • expert β€” Show the Java call stacks for Java threads when the user Java code is executed, and machine call stacks when JVM code is executed, or when the JVM software does not report a Java call stack. Show the machine call stacks for housekeeping threads. the both-worlds option, highkey the overachiever of the trio. 🧚
  • machine β€” Show the actual native call stacks for all threads. This is the view mode for C, C++, and Fortran. raw, unfiltered, native. πŸ’€

🫢 SEE ALSO 🫢

gprofng(1), gprofng-archive(1), gprofng-collect-app(1), gprofng-display-html(1), gprofng-display-src(1)

the user guide for gprofng is maintained as a Texinfo manual. if the info and gprofng programs are correctly installed, the command info gprofng should give access to this document. go read it, bestie, it's free knowledge. πŸ“–βœ¨


Copyright (c) 2022-2026 Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. a copy of the license is included in the section entitled "GNU Free Documentation License". legal slay. πŸ’…


okay that's the whole page!! this one is living its binutils-2.47 era, dated 2026-09-10, and honestly? she ate. go be iconic with your text output. πŸ’–βœ¨πŸŽ€πŸ¦‹

πŸ“¦ where this page comes from