plotting cpu and mem consumption

[vvim]

Hi Group,

for a project[1] I am trying to find an OS independant way to measure the amount of cpu usage

and memory consumption of the program. It would be nice if I could do that in my C++ code, so I

can show the results at runtime or even plot a nice graph (I got wild dreams).

After some google'ing I found some (nice) examples[2] but they are all windows based. Does

universal code for this problem exist?

Of course I can make different classes (one for windows and another for *nix), I do something

similar to assign sockets. But then I also need code for *nix, without using bash-scripting of

course.

So I am looking for something OS independant, but examples for windows or *nix can help me out

for now as well.

Goodnight everyone and thanks in advance,

--wim
______
[1] I am trying to compare some differint multicast protocols, and yes, also cpu usage and

memory consumption is an important part of that :-)
[2] if anybody wants them, I can always post links, just ask

[dimm_coder]

Originally posted by vvim

Of course I can make different classes (one for windows and another for *nix)

That exactly what U should do using C++.
Probably, some scripting languages like Python and Perl have a common interface for doing that stuff, but at any rate its internal realization is system dependent.
It's not necessary to use scripting for *nix-like systems from your c++ program, all information is available from the /proc pseudo-filesystem (read man page for proc).

[vvim]

Yeah, I kind of gave up the search to "universal code" (I just like the sound of it (-. I guess I'll have to write separate implementations for each OS and use conditional compile statements in the source code.

The problem is that I want to do it at run time, in the code itself. the idea is that my program plots a graph (or make a log file, whatever), so every (future) user can see how much resources a protocol uses, without needing to know to go to the /proc-dir

Another major problem is that I haven't found interesting code concerning memory consumption. Until now, I only found ways to measure CPU-cycles and only for windows. Can anyone help me?

Many kind greetings and thanks in advance,

--wim deprez

[TheCPUWizard]

The best solution is (probably) to use OS dependant concrete classes and use the Factory pattern to create the correct instance at run-time.

An alternative, that is (almost) everything independent is to run the collection task at a very low priority. It can then just free update a counter. The more CPU in use be "real" programs, the slower the counter will update. Calibration is an issue. One advantage is that you can play with the priority (usually externally and in an OS dependant fashion) to see what priority tasks are taking up the CPU time.

To repeat, the best solution is to probably be system dependant [e.g. use performance counters on a windows platform], but I did want to point out this alternative.

[dimm_coder]

Originally posted by vvim

so every (future) user can see how much resources a protocol uses, without needing to know to go to the /proc-dir

What I have meant is that various system information is available through the /proc pseudo-filesystem. Your program can extract that information there once per interval (say, N seconds) for building various graphs in real time.
/proc is not a real on-disk filesystem (there are no files on it), but just an interface to the kernel system information (CPU load statistic, processes statistic, network protocols , etc...).
That's a way for *nix-like systems.

[vvim]

Thanks,

Didn't see it like that in the beginning. But I am wondering if it would be a good idea to use a filepointer to read the /proc/stat . Doesn't that give a lot of delay/overhead, or is it neglectable?

#include <stdio.h>
#include <iostream>

using namespace std;

int main(int argc, char *args[])
{
        FILE *statinfo = fopen("/proc/stat", "r");
        char char_read = fgetc(statinfo);
        while(char_read != EOF)
        {
                cout << char_read;
                char_read = fgetc(statinfo);
        }
        fclose(statinfo);
        return 0;
}

For now, it is the only posibility I can come up with. If somebody has a better idea, you're welcome.



And then I still need to find a good solution to check the memory usage. At comp.lang.c++ they referred me to the "Available C++ Libraries FAQ" by Nikki Locke (http://www.trumphurst.com/cpplibs/cpplibs.phtml) but I couldn't find a solution.

Thanks for your help, but I am still on my quest :-)

Many kind greetings,

--wim deprez

[TheCPUWizard]

Doesn't that give a lot of delay/overhead, or is it neglectable?

The answer to this question [regardless of the issue it is being asked about] is MEASURE, MEASURE, MEASURE.

The answer may very well be depemdant on the circumstances. Consider if your machine is running normal desktop apps, and the monitor steals a 50mS chuck of time when it runs [say once per second]. No one will ever notice. Now if the same program is being run on an industrial control computer that needs to service some device every 25mS, execution of your program could cause the system to crash and burn [quite literally in industrial computing].

[vvim]

Yeah of course, you're totally right. But this is probably the only way I can come up with to do it. just asking to board if someone had a better idea. i am totally new to the subject of profiling.

It might not be the best way, but I guess it's a way and if I plan my code well and clean, I can always change tactics.

So for now I'll probably stick to the filepointer for my *nix friends and base the windows code on the examples I found here at CodeGuru (http://www.codeguru.com/Cpp/V-S/debu...cle.php/c4415/) and at CodeProject (http://www.codeproject.com/system/cpuusage.asp).

Still, every suggestion is more than welcome.

Many kind greetings,

--wim deprez

[TheCPUWizard]

and if I plan my code well and clean, I can always change tactics

That's exactly why you define an interface (pure virtual base class) the exposes the "what" of each type of operation you are going to implement. Code to the interface exclusively through your program. Use a Factory design pattern to instanciate the "real" concrete (derived from interface) classes.

Then you CAN easily switch tactics without risking having to modify your program.