dlls/ntdll/file.c: Use FIXME_ONCE for quieter reports.

Max TenEyck Woodbury max at mtew.isa-geek.net
Wed Jul 14 20:58:07 CDT 2010


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



More information about the wine-devel mailing list