Closed Bug 12369 Opened 25 years ago Closed 25 years ago

[PERF] Debug output in optimized builds

Categories

(Core :: DOM: HTML Parser, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: troy, Assigned: rickg)

References

()

Details

(Whiteboard: [19990901] developer regression. troy, is it fixed?)

[Cc'ing Harish on this on so I have a witness] Rick, because of this blunder any future claims you make that the parser (or any future piece of code you write) performs great and isn't a bottleneck will fall on deaf ears While running Quantify on an optimized build with symbols and loading the above URL I noticed that we were spending .10% of the time (that's the 9th highest number with malloc being .30%) in "osstream::<<" Strange, I thought. As I look into it all the calls are coming from the parser. Things like CAttributeToken::DebugDumpSource(). I thought to myself, "Harish is a sensible fellow surely he wouldn't make debug calls in an optimized build". Then I narrow it down to code inside of a "#ifdef RICKG_DEBUG". "Why is that defined for an optimized build?" I ask myself. So I grep the source files and sure enough near the top of CNavDTD.cpp is: #define RICKG_DEBUG #ifdef RICKG_DEBUG #include <fstream.h> #endif Needles to say you need to fix this and fix it quickly...
Blocks: 11702
Status: NEW → ASSIGNED
Stupidity on my part for leaving in debug flags.
Whiteboard: [Perf]
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Fixed by eliminating #defines that enabled debug code.
Whiteboard: [Perf] → [19990826] developer regression. troy, is it fixed?
Whiteboard: [19990826] developer regression. troy, is it fixed? → [19990901] developer regression. troy, is it fixed?
Status: RESOLVED → VERIFIED
Verified fixed per troy
You need to log in before you can comment on or make changes to this bug.