On 07/14/2010 08:53 PM, Chris Robinson wrote:
On Wednesday, July 14, 2010 5:02:59 pm Max TenEyck Woodbury wrote:
'FIXME's that contain no variable
information are completely redundant after their first report. After
the first reminder, the additional reports are just noise. They add no
additional information in terms of action required.
I wouldn't say that. Sometimes the simple knowledge that a FIXME is called a
whole lot says enough on its own (eg, in WineD3D, you get a fixme when an sRGB
reload occurs, because it's a performance drain; if this happens a lot, it can
be taken as a source for performance issues). Sometimes knowing particular a
fixme is triggered near to a crash or other behavioral anomaly can say a bit,
too.
If such fixmes were only printed once, it would be impossible to see this
information without more in-depth testing that most users won't bother with.
If the fixme is only printed once and the rest are TRACEs, it would still
cause more work and a whole lot more noise (ie. all the other traces) in
trying to spot it.
Good points, but the formatting and I/O can contribute significantly to
the lack of performance. There is also the fact that trying to fix
performance problems before you have the operation working correctly is
really poor technique.
Which 'FIXME's for stubs should not be '_ONCE'd is an issue for
specialists. With the new macros, it is easy to back out this kind of
change. Another variation could be made to use an exponential back-off
for the reports. That is, the 2^0, 2^1, 2^2, 2^3, 2^4... instances
could be allowed to print, but that's something that we might want to
discuss before throwing it into the mix of options available. What
would you call that anyway? '_22I'?
