Re: POW: speed up bulk spell checking


Subject: Re: POW: speed up bulk spell checking
From: David Mandelin (mandelin@cs.wisc.edu)
Date: Thu Aug 30 2001 - 10:41:27 CDT


Ben Mesman wrote:
>
> >
> > For the record, AFAIK, win32 has no analogue to gtk_idle_add. But you
> > can use a fancier event loop:
> >
> > while (1) {
> > PeekMessage(...); // extract msg from queue if avail, nonblocking
> > if (got msg) {
> > dispatch it
> > } else {
> > if (have idle function) {
> > cont = true
> > while (cont) {
> > cont = idle();
> > }
> > }
> > GetMessage(...); // extract msg from queue, blocking
> > }
> > }
>
> This may be a good way to implement this on win32, but I can't
> implement this, because I don't have a win32 platform. Look good, but
> shouldn't the 'GetMessage()' be in an 'else' part of the 'if (have
> idle function)'?

No. The idea is that if the idle function returns true, it want's to
continue and it will be called again if the msg queue is still empty.
Otherwise it won't. Once the idle function is done, you just wait for
another message. Actually, there is a bug in the pseudocode, which i
discovered in trying it out. This code works, though:

        MSG msg;
        while (1) {
                if (!PeekMessage(&msg, 0, 0, 0, PM_REMOVE)) {
                        if (idle) {
                                while (1) {
                                        if(!idle->run()) break;
                                        if (PeekMessage(&msg, 0, 0, 0, PM_NOREMOVE)) break;
                                }
                        }
                        GetMessage(&msg, 0, 0, 0);
                }
                if (msg.message == WM_QUIT) break;
                TranslateMessage(&msg);
                DispatchMessage(&msg);
        }

> > It calls the idle function when idle. It doesn't use 100% cpu when the
> > idle function has no work to do. Can this work in gtk?
>
> This could also work in gtk, but it is not realy neccessary. The only
> way AW will take 100% cpu, is when there is a function in the idle
> queue that immediately returns, because it has nothing to do. If we do
> a proper job of timer/idle-queue mainenance, this will not be a
> problem. In the case of spell chacking, this is quite easy, if the
> (dirty-)blockcount reaches zero, we stop the UT_Timer (i.e. remove the
> _backgroundCheck() from the idle queue). When a block is added, we
> already check if the timer is set (and started).

So in gtk, if the idle function doesn't want to be called again, instead
of returning false it removes itself from the set of idle functions? It
should be pretty easy to tweak the event loop to support that.

Well, if you make an XP interface to the gtk idle, I can provide a win32
implementation.



This archive was generated by hypermail 2b25 : Thu Aug 30 2001 - 10:41:46 CDT