Subject: Re: POW: speed up bulk spell checking
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Wed Aug 29 2001 - 01:40:42 CDT
On Tue, 28 Aug 2001, Ben Mesman wrote:
>
> > > The questions:
> > > 1. Where do I implement this? Should there be a special class UT_Idle,
> > > or can we modify the UT_Timer to handle both timer-functions and
> > > idle-functions?
> > > 2. Who will do the other platforms?
> > >
> >
> > These are both tough questions because so far we've explicitly not gone
> > down the threads path.
> >
> > One solution I can think of is to put a bool "bDoAsfastAsPossible" with a
> > default = false in the constructor of the timer functions. Platforms with
> > a mechanism similar to the gtk_idle function could implement it. If not
> > implemented, it defaults to the regular timer semantics.
>
> Just checking if we understand each other: This would mean that at
> creation time of the Timer object, we decide if it should be
> "bDoAsFastAsPossible". If this is "true" the Timer::set() will have
> the same functionality as Timer::start() and the iMilliseconds will be
> ignored.
>
> correct? (or is there a better way?)
>
Yes. That was my orginal thought. I've since realized that this is a bad
idea.
> > A potential problem.
> >
> > 1. When the spell-check queue is empty, does your code keep polling the
> > backgroundCheck method every time gtk_idle say it can? Will this be
> > bad for other methods that might want to use gtk_idle?
>
> I don't know.
>
I've done a little digging. The function in the idle queue will be run at
various priorties as long as they return true. There is a method
gtk_idle_add_priority(...) which takes an integer as a parameter to
determine the priority of running the application.
> I do know that we should make sure that the idle function will only
> fire when there is something to do. If there is always a function in
> the idle queue (even if there is nothing to do) AbiWord will take 100%
> cpu-time (though it seems to be a little bit 'nice' i.e. the system is
> still quite responsive)
>
Yes. I can verify this. I changed the repaint functions to gtk_idle
methods and AbiWord used 100% of cpu time as the repaint function just
idled looking for something to do.
> > (I'm thinking of changing the screen repaints to gtk_idle calls
> > instead of gtk_timeouts. We might come up with other uses for gtk_idle
> > calls too)
> >
> > I'm not saying this is bad. I really don't know what happens when there
> > are several methods in the gtk_idle queue.
>
> I don't know either.
>
> There is also the possibility to set the priority of an idle
> function. Does that mean that a lower priority idle function will
> never get called if there is a higher priority idle function in the
> queue?
>
> I will try to find out.
>
Yes. Once can set the priority but that leaves the problem of how to avoid
100% CPU useage.
Here is an idea. If the function called by ->fire() return false, the
function is removed from the gtk_idle queue.
For a background spellchecking, after each block is spell-checked, the
function could return true if there was another block in the queue and
false if not.
Spell-checking would be restarted via a timer::set() or timer::start() and
continue until all the blocks are spell checked.
What do think?
Cheers
Martin
This archive was generated by hypermail 2b25 : Wed Aug 29 2001 - 01:40:50 CDT