PMPRINTVALUE(3)

πŸ’– PMPRINTVALUE(3) πŸ’–

okay bestie, welcome to the Library Functions Manual corner of the internet, where today's main character is pmPrintValue from PCP 🌸


✨ NAME ✨

pmPrintValue β€” print a performance metric value πŸŽ€


🌈 C SYNOPSIS 🌈

#include <stdio.h>
#include <pcp/pmapi.h>

void pmPrintValue(FILE *f, int valfmt, int type, const pmValue *val,
                  int minwidth);

cc ... -lpcp

like yes, that's the whole vibe. two includes, one function, one link flag. slay πŸ’…


πŸ¦‹ DESCRIPTION πŸ¦‹

So here's the tea: you've got the value of a single performance metric, and that metric is identified by val. pmPrintValue takes that value and prints it onto the standard I/O stream identified by f. that's it. that's the job. iconic. ✨

The way the value gets interpreted depends on two things: the format of val, which is defined by valfmt (that's from a pmValueSet living inside a pmResult structure β€” go peek at pmFetch(3) for that whole situation), and the generic description of the metric's type, which you hand over via type.

The thing you pass as type is typically extracted from a pmDesc structure, right after you've made a call to pmLookupDesc(3) for the particular performance metric you care about. so: look up the desc, grab the type, pass it in. 🫢

The output will be optionally padded so it's at least minwidth characters wide. lowkey a formatting queen.

Where does pmPrintValue really eat though? It's most useful for displaying values of performance metrics from pmFetch(3) β€” and that call returns a set of valfmt and val pairs for each requested metric β€” based upon the metric's type as returned from pmLookupDesc(3). it's giving perfectly matched set. no cap. πŸ”₯


πŸŽ€ ENVIRONMENT πŸŽ€

There are some environment variables that can further control what comes out, and honestly? obsessed.

  • PCP_SQUASH_NEWLINES β€” this one is all about string metric values, bestie. When it's set in the environment of the calling process and the type is set to PM_TYPE_STRING or PM_TYPE_AGGREGATE, then the output value is guaranteed to be free of embedded newline characters. and if the given value did contain such characters? they will have been replaced by a space before being printed. no rogue line breaks sneaking through, periodt. πŸ’€
  • PCP_FLOAT_PRECISION β€” for floating point values (that's type PM_TYPE_FLOAT), the default precision is 8 digits. setting PCP_FLOAT_PRECISION in the environment to some integer value other than 8 will change the number of digits reported, which may be useful to avoid the conversion to ``scientific notation'' that is done by printf(3) for the %g format specifier. acceptable values are β‰₯ 1 and ≀ 10. so don't get cute with it πŸ™ˆ
  • PCP_DOUBLE_PRECISION β€” same energy, double the precision. this one changes the precision of double precision floating point values (that's type PM_TYPE_DOUBLE) from the default value of 16. acceptable values are β‰₯ 1 and ≀ 18. ⭐
not me double-checking those ranges β€” yeah, PCP_FLOAT_PRECISION is 1 through 10 and PCP_DOUBLE_PRECISION is 1 through 18. keep it in bounds or the vibe check fails πŸ’…

🌸 SEE ALSO 🌸

PMAPI(3), pmAtomStr(3), pmConvScale(3), pmExtractValue(3), pmFetch(3), pmLookupDesc(3), pmTypeStr(3) and pmUnitsStr(3). go read them, they're all part of the same friend group 🫢


and that's the whole page, bestie πŸ’œ this one came from Performance Co-Pilot, the PCP girlies, and it's filed under PMPRINTVALUE(3) β€” mwah, go print some metric values, you've got this πŸ‘‘βœ¨

πŸ“¦ where this page comes from