Browse Prior Art Database

Method for profiling background service processes Disclosure Number: IPCOM000240750D
Publication Date: 2015-Feb-25
Document File: 2 page(s) / 44K

Publishing Venue

The Prior Art Database


This article introduces efficient method for profiling background services, daemons or externally triggered programs.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 2

Method for profiling background service processes

When one wants to profile program that is "one shot" executable - that is run it and it performs certain functionality and then finishes profiling is easy. One just runs the program under test along with one of many profilers and then interpret profiler output to know what functions were seen to be executed most frequently. This approach, however, is not feasible to background processes that perform work upon request from other processes. This is due to the fact that process is mostly idle, waiting in pooling loop, on select()-like system call, mutex, semaphore or other synchronization mechanism. This waiting, especially in case of "active" waiting like pooling can severely skew profiling results. There are few possibilities like instrumenting such background daemon process to instruct profiler to start taking samples and then, to stop it (that is tell profiler to only profile tA interval, see figure 1 below). Other is to minimize intervals before daemon activity and profiling start/end. All are either troublesome or inaccurate. We propose to collect two profiles - normal activity and second, profile from time when the background process is idle. Then we can smartly use "idle" profile to extract it from active one to have active profile corrected to only have real profile of active time in daemon.

Assumption is that a background service process usually called daemon needs to be profiled. This process performs some activity triggered by other process by any means (usually some IPC). it is easy to measure how long the daemon was "active" (see fig. 1) - either by getting this info from triggering process or by, for example log analysis. So one can a...