Reproduce: Change EXTRA_DSO_LDOPTS += $(MOZ_COMPONENT_LIBS) to EXTRA_DSO_LDOPTS += -L$(DIST)/lib -lmozutil_s -ltimer_s $(MOZ_COMPONENT_LIBS) (maybe also -lutil ?) in netwerk/streamconv/converters/Makefile Change #define ENABLE_DEBUG_OUTPUT PR_FALSE to #define ENABLE_DEBUG_OUTPUT PR_TRUE in modules/linutil/public/nsTimer.h and add #define MOZ_PERF_METRICS before #ifdef MOZ_PERF_METRICS Recompile netwerk/streamconv/converters/ View a msg Actual Result: Something like MIME Total Processing Time: Real time 1544444:71582814:-2147483648, CP time 5100000000,000 mozTXTToHTMLConv::ScanTXT(): Real time 58333:20:0, CP time 210000000,000 ... should appear on the console. Expected result: Something like MIME Total Processing Time: Real time 0:0:3, CP time ????????,??? mozTXTToHTMLConv::ScanTXT(): Real time 0:0:1, CP time ????????,??? ... should appear on the console. I need a stopwatch for my work on bug #26915, which is sheduled for M14. A simple PRTime parsing = PR_IntervalNow(); ... printf("end %d ", PR_IntervalNow() - parsing); doesn't work, because my function is called multiple times during msg parsing (for every line), and if I measure the whole operation, I have the download included. Maybe it's just a failue on my side, but I found noone, who could help me with that. rhp reports, that the same code worked for him on win32 some time ago (where I tried to get it working the first time, but got the same results). Sorry for the serverity blocker, but I don't know, how to help me anymore.

hmm, I'm not sure chofmann is the correct person for this. Chris - can you pass to the correct person so that Ben can get his M14 bug addressed?

I'm not sure, but this looks like a request for an nspr feature. wtc would be the guy if thats right. supreme hacking monsters sppizter or alecf might have ideas on work arounds or other approaches.

This stuff uses some system calls, I'm wondering if they're just busted, or the calls are wrong.

>I'm not sure, but this looks like a request for an nspr feature. If I'm right, it is an existing feature, that is supposed to work on Linux, but doesn't for some reason.

I only work on NSPR. I do not work on mozilla. I don't understand what is the NSPR feature you were referring to. Is it possible to describe the bug using only NSPR? I don't know what 'stopwatch' is. I don't know what files to look at.

right, this should not be wtc's bug. re-assigning to owner of the component.

I don't know these functions well either, I'm just a user of them. Here's what I found out: I'm using macros from nsTimer.h <http://lxr.mozilla.org/seamonkey/source/modules/libutil/public/nsTimer.h>, which uses Stopwatch <http://lxr.mozilla.org/seamonkey/source/modules/libutil/src/stopwatch.cpp>, which seems to use clock() <http://lxr.mozilla.org/seamonkey/ident?i=clock>.

Have some kind of workaround, removing dependency and lowering severity. However, this bug is still important for my performance work, so severity "major".

cls or other.. do you know what needs to be done to fix this?

*** Bug 36917 has been marked as a duplicate of this bug. ***

The MOZ_PERF & MOZ_PERF_METRICS variables are out of sync.

Content creation time (this=0x8922d68): Real time 0:2:30.0, CP time 80.000 Reflow time (this=0x86acf40): Real time 0:0:10.0, CP time 20.000 Frame construction plus style resolution time (this=0x86acf40): Real time 0:7:30.0, CP time 430.000 There are still a number of entries with times of 0:0:0.0 but that may be normal. Marking fixed.

Thanks for fixing this! Is it/will it be yet checked in? However, I won't have a chance to take advantage of it in the near future - I'm working on other bugs/projects :-(.

It's been checked in.

Per last comments, looks like fixed. Ben please reopen if not the case.

This works on Linux, but the times reported are wrong because sysconf(_SC_CLK_TCK) at http://lxr.mozilla.org/seamonkey/source/modules/libutil/src/stopwatch.cpp#25 never gets called. Additionally, a real time of 10ms is reported as 0:0:0.10 instead of 0:0:0.010 (on all platforms).

Andreas M. "Clarence" Schneider, can you file a new bug, please? I'd like to forget about this old bug. Thanks.

Filed bug 96669.