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'?