On 12/11/06, Josef Weidendorfer <Josef.Weidendorfer@xxxxxx> wrote:
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" ?
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. Marco - 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