On Fri, 10 May 1996, Brian M Grunkemeyer wrote:
> Excerpts from mail: 10-May-96 Re: ideas by Alan Cox@cymru.net
> > We cant afford to blow megabytes of memory on little messages and billions
> > of extra checks that slow the machine down.
>
> Putting a return at the end of such procedures would blow megabytes of
> memory and slow down the machine?
>
> Let me tell you a story. In the early days of Excel, Apple made some
> changes to MacOS that caused the one existing version of Excel to crash.
> Microsoft didn't want to make a crucial change to one of their
> procedures because it added 12 clock cycles to the function, and it was
> a heavily used function. In their 3-hour Excel stress test, that
> function was called 76,000 times. Some programmer went ahead and made
> the change, just to see how much slower the new version would be. It
> was about .1 seconds slower on that 3 hour stress test. The change was
> left in.
>
> I'm not trying to say that optimizations and good algorithms aren't
> important, but this really does present a case for not placing too much
> emphasis on efficiency.
I don't feel free to mention the company or the circumstance, but in
one case I know about, a change to the libraries and kernel to support
C++ across the board cost about 15% in total cycles, because of the
requirement to make/destroy recovery contexts across every system call.
Please remember that if any global or local constructors are or could
be in scope, the routine must establish a context that will be passed
through in the case of a longjmp(). Otherwise, you will have memory
leaks and objects sitting around that can't be dealt with. It was
cheap to drop automatic variables off of the stack. It is much harder
to drop objects out of scope in C++. It is expensive just to set up
for it.
IMHO, C++ and, for that matter, objects, do not belong in kernel
space. It is a matter of adding overhead not to some routine that was
called 76,000 times in a three hour test (12 times 76000 = 912000 - on
a 10 mip machine, this would result in the 10th of a second reported -
a paltry change compared to, say, adding 6 instructions to every
library/subroutine call). You should also carefully evaluate adding
objects to interfaces to system calls in library space. Objects are
fine for *some* user space stuff. Then again, it is up to users what
they put in user space.
But too many objects, and too many routines which use same are totally
anti-performance.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by mkpgp1.6, a Pine/PGP interface.
iQCVAwUBMaoD/hRmU0oGr+olAQH5iQP/Xc2yqUsWNAB7A8PkwTmYW7aBLpRXjrGw
XXFUyPmGLDjZz/JV8Q4YwHCAY7tRnmbRWV5vUzh57uNVmXC4GzKWOUUiypND6B+O
wPDM+nIpphH/cpa64iIFWPwdhFgsip6nnuzsVpEmrApEJt85A77NrNOdZKUkAaQ+
nsHMbkvkHZg=
=UBJc
-----END PGP SIGNATURE-----
Nick Simicich-njs@scifi.maid.com-(last choice) nick_simicich@bocaraton.ibm.com
http://scifi.maid.com/njs.html -- Stop by and Light Up The World!