🚀 go-pugleaf

Goal: Time critical code should perform as well as C code, while retaining the 
advantages of object-oriented design.  Time-critical code in our system includes
polling of hardware devices at a 10mS interval, and processing which will be
on the normal path of execution for peak volume of data items (phone calls).

Coding guidelines:
1. Declare the receiver of a method to be a specific type object, 
rather than an "id". This allows static binding of methods at compile time,
saving most of the 20uS overhead of dynamic lookup.
	Examples:	c_Dpom *vo_self = (c_Dpom *)self;
			P_Connect *vo_pktid= (P_Connect *)ao_pktid;

2. Don't use inherited methods. They cannot be statically bound. 
Inherited data is ok.

3. Don't nest method invocations, since the intermediate results are of 
type "id". Explicitly declare the intermediate variables.
	Example: replace this:
		[vo_class2 m_status:[vo_class1 m_status]];
		
		with
		
		some_value = [vo_class1 m_status];
		[vo_class2 m_status:some_value];

4. Avoid Stepstone library objects such as String, Collection, etc, 
since these do not follow the guidelines given above. 
Code your own objects, and re-use them.

5. Avoid using methods for simple instance variable access, for code within 
the object. Just directly access the instance variable.

Example: Pair of enqueue and dequeue methods, for an event object
to/from an event queue reduced from 200uS to 30uS (on our SPARC
processor board) by following these guidelines.  The queue was
re-implemented as a simple fixed size array, and explicit head and tail
pointers are maintained, rather than using a subclass of ordered
collection. I estimate 5-10 messenger calls were eliminated, each of
which takes about 20uS.

This kind of coding raises all kinds of questions:
	Could Stepstone provide an alternate version of runtime and ICpak101
	libraries, which was optimized for speed?
	
	Could static binding be improved to recognize the type of the receiver
	just from a cast, rather than the data declaration? Can the
	inherited methods be static bound, in code where static (compile-time)
	analysis shows that there is no method over-ride done by 
	the sub-classes?

	Does anyone have any other suggestions for speed improvement,
	which are specific to the Objective-C language (as opposed to
	just general-purpose good-programming practices)?

On un-related issues:
	Can the .h files be enhanced to declare certain methods as internal 
	or private to an object? I frequently have the case where the
	public interface is only a few methods, but for modularity reasons
	I have a dozen internal methods. At present they are all listed
	in the header, with only a comment to protect them from another
	programmer attempting to use them.
	
	If the function names the objc pre-processor generated were changed from
	"_23_class" (for example) to "_23_class_my_method_name" it would make them
	more readable, especially in dbxtools where the function name is displayed.

	matt