Re: Profiler class, suggestions and comments welcome
On Aug 19, 6:02 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
Francesco wrote:
I lack the knowledge to properly use debuggers and profilers
that come with Code::Blocks.
Don't worry. I don't even know what "Code::Blocks" is.
Still, learning to use a debugger and a profiler is essential.
Unless you never need them. (It's not that frequent to need a
debugger; I probably use one about twice a year. A profiler is
almost essential in any application where CPU time is
relevant---which isn't all that many, either.)
Here is my profiler class. A couple of questions right after it:
-------
// combining header and implementation for easy copy&paste
// header (double-inclusion check snipped out)
#include <string>
namespace profiler {
class Profile {
public:
Profile(std::string = "");
For the sake of performance (and with a profiler it's kind of
important, wouldn't you say?) you should *never* pass objects
of class type by value. *Always* prefer passing by a const
ref, unless there is a strong reason not to.
Well, his class isn't really a profiler:-), and the pass by
value occurs outside of the code being benchmarked, so it
doesn't matter. But while it's probably a blatant example of
premature optimization, the usual convention is to pass class
types and (usually) unknown types (e.g. in templates) as const
references, other types by value. And as usual, deviating from
an established convention causes confusion in the reader, and
should be avoided if not necessary.
~Profile();
private:
std::string id;
Since your individual object survives only until the end of
the scope in which it was created, consider storing the start
clock value in it, instead of in a separate table. Then in
the destructor calculate the difference and store it in the
table (also see below for more recommendations).
};
std::string report();
}
// implementation
#include <ctime>
#include <map>
#include <sstream>
// profiler's header inclusion snipped
struct time_pair {
clock_t start;
clock_t stop;
};
typedef std::map<std::string, time_pair> time_map_type;
time_map_type time_map;
profiler::Profile::Profile(std::string s) {
id = s;
*Always* prefer initialisation (using the initialiser list)
over assignment. There is a FAQ about that. Have you
actually read the FAQ?
clock_t& rct = time_map[id].start;
rct = clock();
}
So, your function here could be written as
profiler::Profile::Profile(std::string const & s)
: id(s)
{
time_map[id].start = clock();
}
Except that, as he mentions, this might result in the time used
to lookup the value in the map being included in the measured
time. Or not, depending on the compiler, the various
optimization options, etc.
Your suggestion to store the start time in a member was, IMHO,
the right one. In particular, it probably means that he doesn't
need to store the start/stop times in the map, only the
interval.
Also, consider that the results of profiling of any particular
function are overridden by a subsequent calls, so you might
consider improving your system to (a) count the number of
calls to that particular function and (b) accumulate the
overall time spent in it (instead of recording start-stop
ticks):
struct timing_result {
int hit_count;
clock_t total_time_spent;
};
This is, I think, a very good idea. At least if he wants a
profiler, and not a benchmark harness:-). (His solution
implements more of a benchmark harness. Your's really is a
profiler.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34