Re: [RFC \ WISH] Add -o option to git-rev-list

From: Marco Costalba <mcostalba@gmail.com>
Date: Dec 11, 2006, 17:28 UTC
Message-ID: <e5bfff550612110928h41e05acah4f835caa3fa6fea5@mail.gmail.com>
In-Reply-To: <200612111428.29390.Josef.Weidendorfer@gmx.de>

On 12/11/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:

Show 14 quoted lines

> On Monday 11 December 2006 13:52, Marco Costalba wrote:
> > On 12/11/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> 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.