If anything, MUMPS tends to benefit from the principal of locality -- global nodes typically fit comfortably in a single disk block, whereas tables and individual rows (or tuples) are frequently larger. In fact, the block size on the PDP-11/70 was 512 bytes, half of which is the maximum string length in the portability standard! Another area in which MUMPS benefits is that it has traditionally done its own process management (often even running on operating systems like DOS) making cache management much easier.
But think about it: Is C fast because it is based on an abstraction that is similar to the underlying instruction set? Hardly. C has much more in common with languages like Pascal than it does assembly language (never mind lower levels of hardware architecture). But this is a different problem you say? Not really. It may be that main problem faced by a DBMS designer is the high cost (and slowness) of disk I/O. But is that really so different from the problem faced by a compiler designer faced with the difference in cost of register access and conventional memory access, or the hardware architect faced with a trade-off between on-board and off-board memory. The basic problem is always the same: using limited fast resources to the best advantage while trying to limit the extent to which calls are made to more plentiful cheap resources.
Before I get off my little soapbox here, I should add that I believe one of the thins that makes people nervous about MUMPS is the cultural assumption that the key to efficiency is eschewing high level abstractions (as if though MUMPS were not replete with such abstractions already!)
Frankly, this makes me a bit nervous, too.
==== Gregory Woodhouse [EMAIL PROTECTED]
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
