Talked with Eric some about this, and I think my perspective is skewed about how we use SpeedTracer in the compiler and devmode. It seems to me that the ideal behavior there is to only flush on every top level event. There are so few of them, and we don't care about a small amount of work going on in between them. That'd be trivial to both implement and understand. I can see how if you had a lot of top-level events calling flush for each one probably wouldn't be desirable.
On Wed, Feb 23, 2011 at 2:14 PM, Scott Blum <[email protected]> wrote: > On Wed, Feb 23, 2011 at 1:16 PM, Toby Reyelts <[email protected]> wrote: > >> I'm concerned about how this might impact logging results. For example, >> even if the results are written out on a separate thread (and assuming the >> box has an entirely free processor to deal with it), you can still cause the >> disk to be busy with I/O during the writes, slowing down the real time of >> the even thread if it's also doing I/O. Basically, we already have enough >> problems with reproducible results, so I hate the idea of adding even more >> non-deterministic behavior to the mix. > > > FWIW, the LogWriterThread already is going to randomly flush itself when > the buffers fill up, so it's probably not any less deterministic to flush it > on a regular basis. The "streamed output from dev mode" seems like a > reasonable use case, even flushing every second or two shouldn't impact > performance. > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
