Tradeoffs around Node::Opcode()?

[Peter B. Kessler]

Cool!  Thanks.  So much for engineering: we already have *both* the virtual dispatch *and* the data slot per instance.

Oh, but those are only the class id's (e.g., Add), rather than the opcode (e.g., AddI).  It's confusing that they are both referred to as Node "classes", e.g., in classes.hpp, opcodes.cpp, etc.

So I guess that begs the question: why *isn't* there an _opcode field, initialized in the constructors, like (or instead of) _class_id?  Why aren't the leaf classes (AddI, etc.) in the _class_id maps?  (Other than that the _class_id maps want to fit in a jushort. :-)  Couldn't one map (e.g., with a table) from an opcode to a _class_id, if one wanted to spend the time as opposed to the space?  Would an inline method to access a _class_id table be faster than a virtual dispatch to Opcode()?

A possible answer as to why it is the way it is: "History".

I'm still trying to understand the tradeoffs between space and time.

			... peter

Vladimir Kozlov wrote:
> Peter,
> 
> There is already such functionality exactly for such purpose.
> The field is jushort _class_id; which use enum NodeClasses
> and initializer in the constructors init_class_id().
> 
> Vladimir
> 
> Peter B. Kessler wrote:
>> A lot of things in class Node are organized around having a dense 
>> integer range to identify the Node.  That's Node::Opcode().
>>
>> I'm wondering about the engineering around that method.  
>> Node::Opcode() is a virtual call, to get from a Node instance to a 
>> piece of data on the Node subclass of the instance.  An alternative 
>> would be to add a data field in Node to hold the opcode, and replace 
>> the virtual Node::Opcode() calls with an inline method to return the 
>> contents of that slot.  That trades the virtual dispatch cost for each 
>> call with a space cost in each instance.
>>
>> Does anyone have any feeling about whether that's a good tradeoff?  
>> How often is Node::Opcode() called?  What effect would it have to make 
>> it run faster?  How important is it to minimize the size of Node 
>> instances?  (There are other places where effort is expended to keep 
>> Node's small.)
>>
>> Thanks for any opinions on this.
>>
>>             ... peter