Fwd: OutputModel performance

Milian Wolff mail at milianw.de
Sun Mar 17 01:52:20 UTC 2013


On Sunday 17 March 2013 02:40:05 Milian Wolff wrote:
> On Friday 08 February 2013 00:29:12 Andreas Pakulat wrote:
> > Hi,
> > 
> > On Thu, Feb 7, 2013 at 11:09 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> > >> b) create an active worker object that is moved to a thread, then let
> > >> that do the classification. I.e.:
> > >> 
> > >> output line (QString) -> active object, run regexps -> (Categorized
> > >> Data)
> > >> -> OutputModel
> > > 
> > > I'd rather have a worker-object running in a QThread-with-event-loop,
> > > this has a slot to give it lines and emits a signal with batches of
> > > parsed-data (i.e. 50 or so). Then every time lines are added to the
> > > model, a signal is emitted which connects via queued-connection to the
> > > worker, that one adds the lines to its internal queue and processes
> > > lines. Once it has a batch of 50 done, it emits them and the
> > > outputmodel gets that through a queued-connection to add it to the
> > > model data and notify the view. That should be safe enough to not
> > > introduce many regressions and should solve the ui-lockup.
> > 
> > Since I was bored I've tried this now in the
> > wip/filter_output_threaded branch. Unfortunately the outputmodeltest
> > crashes and I'm too tired to debug the reason, its likely though
> > because the outputmodel is deleted while the background thread is
> > still running. I don't see a good way of stopping it earlier than the
> > destructor at the moment.
> 
> Fixed that some time ago and finally merged the code into master now.
> 
> Please test, everyone!

One thing I notice is that the 100ms delay to wait for more lines to fill a 
batch makes the output really sluggish imo. Do we really need that whole batch 
processing now that we have uniform row heights and such? I.e. is it really so 
much faster to add 50 lines in one go VS one line after another?

Cheers
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20130317/9fca2056/attachment.sig>


More information about the KDevelop-devel mailing list