Event Profiler Timers?
Andreas Ericsson
ae at op5.se
Wed Jun 10 17:56:42 CEST 2009
Hmm. I'm getting extremely long lines from your mailer, which
forces me to rewrap everything, but that messes up code snippets.
Any chance there's some setting you can fiddle to make it actually
insert linebreaks every 72 chars or so?
Steven D. Morrey wrote:
>>
>> Otoh, it might be worth doing something like this:
>>
>> clock_t start; double delta;
>>
>> start = clock(); do_stuff(); delta = clock_delta(start, clock());
>>
>> static double clock_delta(clock_t start, clock_t end) { if (end >
>> start) { /* normal case */ delta = (double)(end - start); } if (end
>> < start) { /* wrap-around */ delta = (double)(end + (1 <<
>> (sizeof(end) * CHAR_BIT))); delta -= (float)start; }
>>
>> return delta / CLOCKS_PER_SEC; }
>>
>> which should always provide the value as a fraction of seconds,
>> which is almost certainly how you want to display it anyways.
>
> This is fantastic information, and oddly enough explains a bug in a
> game server I once worked on, every hour and 15 minutes it would kick
> all the players out. It was a truly nasty and annoying bug but now I
> know how and why it did it, so thanks for the excellent information.
>
You're welcome.
>> On a side-note, try to use arrays of doubles to store the total
>> delta. It's much neater than having multiple global variables.
>
> Yeah I'm going to make some changes to this and create a new profiler
> struct that holds both the timer and the counter, then create an
> array of those using the event type as a key, it'll make maintaining
> and extending a lot easier.
>
>> The clock_delta function is also quite easily testable which
>> alleviates the worries about the wrap-around case not being tested
>> much.
>
> Mind if I steal this code for something unrelated?
>
Go wild. It's too simple to be anything but public domain code.
>>> With gettimeofday we are talking about how much calendar time has
>>> been spent, whereas with clock we are talking about how many
>>> ticks were used by the program and then dividing that by
>>> clocks_per_second to get a process time. I believe that clock
>>> would be more accurate since it filters out the cost of other
>>> processes running on the system.
>>
>> True, but the meaning of it would be hard to correlate against
>> latency, since some events spend an inordinate amount of time
>> switching contexts while others are fairly cpu-intensive but
>> achieve a lot in wallclock time. Parsing passive check-results is
>> CPU-intensive, but in wallclock time we can easily parse 50 or 100
>> of them in the same time it takes to fork and fire up a plugin. I'm
>> not sure which of the values would be preferrable here, and I'm
>> also not sure which of the processes gets the CPU-time attributed
>> to it.
>
> I really can't win for loosing with this one can I? No matter which
> way we profile there is going to be either something added or
> something missing.
>
Well, you could profile both. The overhead really shouldn't be
prohibitive. If you do though, please add it as a separate library
thing so we can re-use the same code for other things as well.
I've got something similar for PHP which I call "sprof" (for
"section profiler"). It's a bit more complete and lets you name
each section and extract information about it later, but it'd be
total overkill for something as silly as this, tbh.
> Thanks again for taking the time to read this.
>
Np. Decent profiling would be nice to have.
--
Andreas Ericsson andreas.ericsson at op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
More information about the Developers
mailing list