[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: rewriting proxies' sending half
- To: <markm>, <michael>
- Subject: Re: rewriting proxies' sending half
- From: Chris Hibbert <hibbert>
- Date: Mon, 13 Aug 90 14:23:42 PDT
- Cc: <xtech>
Michael asked a very perceptive question:
What are you buying, besides the appearance of simplicity in the
It isn't execution time: ...
No, this is too early in the game for that, and no one has complained
about the speed of this code.
It doesn't appear to be code size ...
That is the point here. Thanks for showing how VarArgs really doesn't
save me space, and thanks to MarkM for showing an efficient way to get
away from VarArgs.
I've been mostly going on guesses as to what the objective of this
exercise is. I've had various people tell me that the problem that
needed solving was either absolute size of code, (because some of
the compilers we want to use are getting close to or had passed
their limits) or that the problem had to with the absolute number
of methods (because the Macintosh has some limit we're approaching
on the total number of vtable entries?)
When I was working on the first part, it didn't seem to matter much,
since I could get rid of a huge number of classes, (one per PROXY
method) each with two methods, and that would serve both purposes.
In the current part of what I'm doing (which may be past the point
of diminishing returns) it's harder to tell. Each Proxy class has
to have a method for each message of the class it represents, so
there's no reducing the number of those. That leaves me trying
to reduce the amount of code those methods use. Is this very useful?
Assuming it is, here's my modified approach: I use MarkM's idea
about putting the handleSend(...) methods in the abstract message
description objects, then I can get rid of all the problems with
using VarArgs, and use the other speedup ideas that Michael
suggested without worrying about code space very much.
I just ran a
grep ... */*s.cxx | sed ... | sort | uniq
script and it looks there are only 20 abstract signatures that
ever get used out of about 700 methods. That means that the space
that the handleSend messages use doesn't matter much, and I can
worry about speed there instead.
So, in addition to the list Michael gave, I get to add 20 versions
of handleSend() each with a specific (not VarArgs) signature.
Each of those uses the calls he listed for CommXcvr, unless there
are places I decide to go for clarity instead of conciseness.