From: Josef Weidendorfer Date: Mon, 11 Dec 2006 13:28:28 GMT Subject: Re: [RFC \ WISH] Add -o option to git-rev-list Message-ID: <200612111428.29390.Josef.Weidendorfer@gmx.de> In-Reply-To: On Monday 11 December 2006 13:52, Marco Costalba wrote: > On 12/11/06, Josef Weidendorfer 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?