[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
for Performance Engineering phase: Can Vars be roots?
- To: <roger>
- Subject: for Performance Engineering phase: Can Vars be roots?
- From: Mark S. Miller <mark>
- Date: Thu, 15 Feb 90 12:06:40 PST
- Cc: <xtech>
- In-reply-to: <Roger>,37 PST <9002131944.AA03311@xanadu>
Date: Tue, 13 Feb 90 11:44:37 PST
From: roger (Roger Gregory)
From vlad!mark Tue Feb 13 01:41:04 1990
An interesting possibility ... is to have IntegerVar's and
CheckedPtrVar's not be Var's nor Tofu's. Instead, they
could be their own root class. ...
So what if they have vtables? Does'nt that just cost us on the virtual
function calls. If they are leaf then it costs nothing.
Since the internal state of essentially all of our objects consists of
IntegerVars & pointers to other objects, a vtable in the pointers &
the IntegerVars themselves almost double the size of our objects, and
lengthen the time to initialize them. With all our other classes,
this is not an issue.
I've just recently (with Michael) looked at the code for CheckPtrVars,
and confirmed that, if we get rid of the vtables, then with
development-time error checking turned off (both the DANGLE_CHECK and
the NULL check), and promiscuous use of inlines, CheckPtrVars should
have *zero* overhead over C pointers for pointer operations. I think
this is important, because everything else is built on top of pointer
operations. (Of course, they are more expensive during garbage
collection, but that's what they're about.)