Well as soon as you built any abstraction of the object in AutoHotkey this overhead happens anyways. I dont seriously believe that you want people to use non-descriptant numGet combinations in their code.
So as soon as we use any sort of object to get a table offset or to access the table at an offset using numGet we have more overhead at runtime than just storing the result of the numGet inside an object.
The only way around the object is using a set of variables. But maintaining a set of variables for every COM Object that you use and makeing them consume the super global scope is not really an option towards me.
When using the objects you have several options:
In this design you store the offset of a function in the COM Objects v-table inside an object.
Then you use NumPut + DllCall every time you want to call it. e. g.:
This method brings the full overhead of the NumPut and the Object access.
The advantage is that you dont need to prepare anything special for each object.
Pointer-Object: (the thing I thought about when making my last post)
In this design you store the result of the NumGet inside the object.
Then you use DllCall every time you want to call the function thats stored inside. e. g.:
This method only needs the Overhead of the object access and saves the numGet.
The disadvantage is that you need to save every function pointer for every COM object inside a new functionPtr Object.
In this design you just use the non-descriptant NumGets with fixed offsets in several class methods
Then you just use the method everytime you want to access the object:
This method has a lot of hidden overhead and is slower then the other 2 - though it is also easier to use.
It has 2 object accesses and numGet.
There are several more designs however after thinking about it in depth it seems like creating a special struct for each vTable is the best option after all.