Xref: utzoo comp.sys.ibm.pc:51662 comp.os.minix:10968 comp.unix.xenix:11834 comp.realtime:672 comp.arch:16227 Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!daver!tscs!tct!chip From: chip@tct.uucp (Chip Salzenberg) Newsgroups: comp.sys.ibm.pc,comp.os.minix,comp.unix.xenix,comp.realtime,comp.arch Subject: Re: Bloat costs Message-ID: <266577FA.6D99@tct.uucp> Date: 31 May 90 20:00:58 GMT References: <2662D045.3F02@tct.uucp> <442@van-bc.UUCP> Organization: ComDev/TCT, Sarasota, FL Lines: 24 According to jtc@van-bc.UUCP (J.T. Conklin): >I'm sure that many faster algorithms had to be passed by because >of limited address space. Some of the GNU equivelents of UNIX >programs are many times faster because of the faster, yet more >memory intensive, algorithms. However, as has been pointed out before, the memory isn't free, paging takes time, swap space isn't free, etc. At the very least, where practical, programs with memory-eating algorithms should include a more frugal algorithm as an option. IMHO, of course. >Another unrelated application is high resolution image processing. Is >procesing 16MB frame-buffer with kerjillions of processors doing ray- >tracing wasting mmoryy? Well, there are exceptions to every rule. :-) >On the other hand, there is something to be said about giving >beginning programmers 6 MHz Xenix/286 machines to work on. Amen. -- Chip, the new t.b answer man ,