[Users] Couple of small patches

[Olivier Brunel]

On Thu, 20 Dec 2018 16:41:48 +0100
wwp <subscript at free.fr> wrote:

> Hello Olivier,
> 
> 
> On Thu, 20 Dec 2018 16:33:21 +0100 Olivier Brunel <jjk at jjacky.com>
> wrote:
> 
> > On Thu, 20 Dec 2018 09:00:04 +0100
> > Colin Leroy-Mira <colin at colino.net> wrote:
> >   
> > > On Wed, 19 Dec 2018 17:12:18 +0100, Olivier Brunel
> > > <jjk at jjacky.com> wrote:
> > >     
> > > >  		procmsg_msginfo_free(&msg);
> > > >  
> > > > +		gtk_main_iteration_do (FALSE);
> > > >  		if (progress_cb != NULL      
> > > 
> > > Doesn't performing a gtk iteration each message drop search
> > > performance badly ?    
> > 
> > Well, I didn't do extensive testing, but I couldn't really notice
> > any diferences when I tried things. Also, I (obviously) have this
> > applied here, and - though I'm not doing comparison - my searches
> > don't seem slow(er) to me. Of course, it might also depends on
> > other factors, one's setup, etc. YMMV.
> > 
> > (I'd say most of the times GTK should just check that there are no
> > pending events and return immediately anyways.)
> > 
> > So I would say 'no' to the "hurt badly" idea; And though I'm sure it
> > does affect it somewhat, for me it doesn't seem noticeable.  
> 
> I was already doubtful but there you're not really convincing me this
> patch could make things better ;-).

Well, obviously this wasn't intended to make things better wrt speed.
And since more code is added, as little as it may be, one could argue
it has to have an impact, and that can only go one way.

What I'm saying is that, AFAICS, said impact seem minimal (not
noticeable in fact) whilst the impact for what the patch is intended,
i.e. making the UI more responsive, is clearly there.
At least for me, when running long/slow searches, I can cancel them
quite easily/rapidly with this patch. Without, it's quite another
story...