Closed Bug 12369 Opened 25 years ago Closed 25 years ago

[PERF] Debug output in optimized builds

Categories

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

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: troy, Assigned: rickg)

References

(
URL
)

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.