On Monday 11 December 2006 13:52, Marco Costalba wrote: > On 12/11/06, Josef Weidendorfer <Josef.Weidendorfer@xxxxxx> wrote: > > On Monday 11 December 2006 01:15, Marco Costalba wrote: > > > guiUpdateTimer.start(100, true); > > > > What is the result with "guiUpdateTimer.start(0, true);" ? > ... > IOW you suggest to use a brute force polling of the pipe. Ah, yes. That is probably not what you want. Why did you introduce the timer at all? What was the problem with QProcess and handling its signal "data available" ? If you do git-rev-list | cat > /dev/null the consuming "cat" will do a blocking read, and this should have the same property "handle data as fast as possible when they come available" as QProcess with handling the data in the handler of QProcess' signal "data available". If it is about postprocessing the small data chunks you get (and the double copy in memory), I do not think this is a problem: a machine noadays usually should handle 1 GB/s bandwidth to memory. You probably are loosing more with your 100ms timer. Or am I missing something? Josef - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html