From: Marco Costalba Date: Mon, 11 Dec 2006 17:28:46 GMT Subject: Re: [RFC \ WISH] Add -o option to git-rev-list Message-ID: In-Reply-To: <200612111428.29390.Josef.Weidendorfer@gmx.de> On 12/11/06, Josef Weidendorfer wrote: > 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" ? > I did. Actually the released 1.5.3 version and all the verions before that do use QProcess, but I experimented an increase in performance reading the data on a timer instead of on "data available" signal. BTW that observation led to all this stuff ;-) The problem is that the frequency of the signal is very very high because the producer can write a big amount of data with great speed. We are talking of a signal "data available" each few ms. By the way of experimenting with QProcess I have found it's better a timer when the stream is very very fast, _then_ I have update the reading code to take _more_ adavntage of the big chunks we were reading with a low frequency timer and avoid a double copy, but the increase was _already_ present also with the double copy needed by the original 'small chunks handling' code activated by "data available" signal. If you take a look at released qgit you will see, in dataloader.cpp the reading slot called on the signal.