The cost entities known to KCachegrind are given in the following. Simple Positions: Instruction. An assembler instruction at a specified address. Source Line of a Function. All instructions that the compiler (via debug information) maps to a given source line specified by source file name and line number, and which are executed in the context of some function. The latter is needed because a source line inside of an inlined function can appear in the context of multiple functions. Instructions without any mapping to an actual source line are mapped to line number 0 in file "???". Function. All source lines of a given function make up the function itself. A function is specified by its name and its location in some binary object if available. The latter is needed because binary objects of a single program each can hold functions with the same name (these can be accessed e. g. with dlopen/ dlsym; the runtime linker resolves functions in a given search order of binary objects used). If a profiling tool can not detect the symbol name of a function, e. g. because debug information is not available, either the address of the first executed instruction typically is used, or "???". Binary Object. All functions whose code is inside the range of a given binary object, either the main executable or a shared library. Source File. All functions whose first instruction is mapped to a line of the given source file. Class. Symbol names of functions typically are hierarchically ordered in name spaces, e. g. C++ namespaces, or classes of object oriented languages; thus, a class can hold functions of the class or embedded classes itself. Profile Part. Some time section of a profile run, with a given thread ID, process ID, and command line executed. As can be seen from the list, a set of cost entities often defines another cost entity; thus, there is a inclusion hierarchy of cost entities which should be obvious from the description above.
Елементи вартості, відомі & kcachegrind;, може бути подано у наведеному нижче вигляді. Прості позиції: Інструкція Інструкція асемблера за заданою адресою. Рядок коду у функції Всі інструкції, які компілятор (за допомогою відомостей для усування вад) пов’ язує з заданим рядком коду, який визначається за назвою файла і номером рядка і який виконується у контексті певної функції. Останній потрібен, оскільки рядок коду у вбудованій функції може з’ являтися у контексті декількох функцій. Інструкції без жодних прив’ язок до справжнього рядка коду пов’ язуються з рядком з номером 0 у файлі???. Функція Всі рядки коду певної функції самі складаються з функцій. Кожна функція задається своєю назвою і розташування у певному бінарному об’ єкті, якщо він доступний. Останній потрібен, оскільки бінарні об’ єкти окремої програми можуть міститися функції з однаковими назвами (до цих функцій можна отримати доступ, наприклад, за допомогою dlopen або dlsym; інструмент прив’ язки під час виконання визначає функції у вказаному порядку пошуку використаних бінарних об’ єктів). Якщо інструмент профілювання не може визначити назву символу функції, наприклад, оскільки інформація для усування вад недоступна, буде типово використано або адресу першої виконаної інструкції, або???. Бінарний об’ єкт Всі функції, чий код перебуває у діапазоні вказаного бінарного об’ єкта, основного виконуваного файла або спільної бібліотеки. Файл вихідних кодів Всі функції, перша інструкція яких пов’ язується з рядком певного файла вихідних кодів. Клас Символічні назви функцій, типово, впорядковано за просторами назв, наприклад, просторами назв C++ або класами у об’ єктно- орієнтованих мовах; отже, клас може містити функції класу або самих вбудованих класів. Частина профілювання Певний часовий розділ запуску профілювання з певним ідентифікатором потоку, ідентифікатором процесу і рядком команди, яку слід виконати. Як можна бачити зі списку, набір елементів вартості часто визначає інший елемент вартості; таким чином, існує послідовна ієрархія елементів вартості, структуру якої можна зрозуміти з наведеного вище опису.