Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!ge-dab!tarpit!bilver!alex From: alex@bilver.uucp (Alex Matulich) Newsgroups: comp.sys.amiga.misc Subject: Re: Gomf is CPU greedy! Message-ID: <1991Jun4.155620.10161@bilver.uucp> Date: 4 Jun 91 15:56:20 GMT References: <223@taloa.unice.fr> <1991Jun3.111119.8148@cs.uow.edu.au> Organization: W. J. Vermillion - Winter Park, FL Lines: 33 In article <1991Jun3.111119.8148@cs.uow.edu.au> u8705377@cs.uow.edu.au (Paul Anthony Wilkinson) writes: >beust@taloa.unice.fr (Cedric Beust) writes: >> I wanted to have statistics about the CPU use on my Amiga and was >>very suprised to see that gomf (3.0, so launched via runback) used >>about 12 (twelve!) percent of CPU time, and in READY mode, not >>WAITING. So I decided not to use it any more. My understanding is that GOMF is one of those tasks that dynamically adjusts its CPU use. If your Amiga is idling, GOMF will use more. Anyone know differently? >I stopped using Gomf at version 2.0 when I found that it was using a large >chunk of CPU time. I suspect it is because it frequently checks lowmem to see No, it doesn't. You need to use another utility like MemGuard for this. >if someone stomped on it via a NULL pointer etc. I also found that when >GOMF did catch my programs that left locks open & stuff and I had to reboot >anyway. The simpler solution is just not to make programming errors 8-) . GOMF has saved my ass so many times while programming, that I do not want to give it up. True, I often re-boot anyway after a crash, but I like the added comfort of being able to clean up complicated projects, examine temporary ramdisk files, etc, before re-booting. In actual timing tests, I have not noticed GOMF to slow down any application that I run. -- _ |__ Alex Matulich /(+__> Unicorn Research Corp, 4621 N Landmark Dr, Orlando, FL 32817 //| \ UUCP: alex@bilver.uucp ...uunet!tarpit!bilver!alex ///__) bitnet: IN%"bilver!alex@uunet.uu.net"