[PATCH] deferred trace

[gerard patel]

At 11:24 AM 10/03/2001 -0800, you wrote:
>gerard patel <gerard.patel at asi.fr> writes:
>
>> This implements a way to not output the debug trace to disk until the
>> user hits Alf + F12. The goal is to avoid too big trace files.
>
>I think it would be much better to do that with a small external
>program that you pipe the debug output into. This way you can have
>much more flexibility

I don't see why.

2 other points :

1) I  wonder if I will not lose in speed with this approach; it seems to be
more efficient to stop the output ASAP, than to filter data after it has passed
through a pipe. I have timed Bcb4 loading with Wine on my
computer (K6-350)

- without any trace : 48 seconds

With a simple -debugmsg +win,+relay :

- with my patch : 70 seconds -> 22 seconds overhead
- with a redirection to /dev/null : 95 seconds -> 47 seconds overhead

I don't know if a pipe would be more efficient that a redirection,
though.

2)  I don't see how I will get the window list I generate with
WIN_WalkWindows if there is no change at all in Wine - I should
have said that to cut in the trace size in not a goal per se, but a
mean to make debugging easier. 
If I have to make a first run with full trace that I have to browse to see
what is the meaning of the window handles appearing in the trace, I lose 
a lot of time. Having immediately a view of all existing windows is *very*
handy.

>, and you don't need to hardcode a specific key
>that some apps may need.

But my patch does not use the Alt+F12 key if the -dt command
line option is not used. It's true that some apps use this key, but in this
case it's only debugging that is affected because the app does something
when I use this key. It has never been a problem until now.
Maybe a signal could be used instead.

Gerard