chris@mimsy.UUCP (Chris Torek) (09/05/87)
On the other hand, these editors, compilers, and other utilities that fit in a small space do not get away without paying something for it: Most of them (as was just observed in re benchmarks) use temporary files and so do quite a bit of I/O. Last night Fred Blonder wrote an anagram unscrambling program. It is quite small, 40K even with all the runtime goo allocated by the 4.3BSD C library. It gets away with this by rescanning the dictionary when it recurses (it will tell you that an `umbrella' can be `all umber' and owned by `earl blum'). It would go much faster if he read in the entire dictionary once, and made up its histogram information and kept it in core. (On the other hand, it would also go faster if it copied the dictionary to histogram form in a file. Well, what do you expect from a 30 minute hack?) The point is that `small' is usually just one end of a long space/time tradeoff line. (But remember that an infinite amount of memory takes an infinite amount of time to access :-) .) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris