| Despite the fact that Hugs1.3c is supposed to be a 32-bit application, it
| consumes 100% of the CPU even with no program running. I've seen similar
| behaviour when running 16-bit apps in NT. Is Hugs REALLY a true 32-bit
| program?
To ensure that the Hugs for Windows GUI will respond properly to user
actions (such as a click on the stop button when the evaluator is
running), it polls the event queue quite frequently, looking for things
to do. The same technique is used in both the 16 and 32 bit versions
of the user interface, and has quite a noticable effect on performance
(making it look as though the machine is running at 100% CPU). The
problem is most easily observed using the Task Manager on Windows NT
(or similar tools on 95). (It also interferes with Hugs programs that
would like to create windows and graphics of their own because this
would cause competition for incoming events. This is why Fran can't be
used in the Hugs for Windows GUIs, for example.)
A better solution would be to use separate threads so that we could
have a responsive user interface on top of a faster evaluator, without
using 100% CPU while the system is supposed to be idle. Unfortunately,
that wasn't possible in a system that was originally designed to target
older versions of Windows.
Incidentally, while Hugs for Windows may have some problems, it's still
my preferred interface to Hugs: it's "fast enough" for the things that
I need to do, and the browsers are pretty handy. Let me not forget to
give due credit to Jose Enrique Gallardo, who did most of the hard work
in building the interface on which Hugs fow Windows is based!
I hope that there will be a multi-threaded version of Hugs for Windows
that will give all the nice features of the current GUI without the big
performance hit. (But that's not a project that I am currently working
on.)
All the best,
Mark
