This question has been asked a number of times on the DGD mailing list, where large refers to a lot of functions. Dworkin has replied to this and stated that the function lookup time is constant and independent of the number of functions in the auto object. However, he has also said:
There is an obscure cost associated with functions in the auto object that are neither static nor private: all such functions have a cost of two bytes a piece in <every> inheriting object's program. This is also true for non-private functions in all other (i.e. non-auto) objects.
Normally, this is not much of a problem. However, if you were to have 200 such functions in the auto object, every other program in the game but that of the driver object would become 400 bytes larger.
It is not unreasonable to assume that functions in the auto object that are neither static nor private are uncommon.
On the related question of using an inherited module rather than placing the code in the auto object Dworkin made the following statements:
- A call to a function in the auto object uses the special CALL_AFUNC instruction, which is 3 bytes in size. Exactly the same functionality would be available with the CALL_DFUNC instruction, which takes 4 bytes. Thus, programs that call functions in the auto object will be slightly smaller. In the most extreme case, a function that consists of nothing but function calls will be almost 25% smaller if CALL_AFUNC can be used for every call. There will be a barely measurable performance difference.
Note that programs larger than 2K are compressed before being saved in the swap file, where the compression factor depends on the redundancy of the byte code, so the size advantage in the swap file would be much less than 25% if the function mentioned above is large enough.
- Inheriting a utility object, which itself does not inherit anything, increases the size of the inheriting program with about 16 bytes.
- Putting everything into the auto object increases the size of the working set. For a single object the difference won't amount to much, but a mudlib wholly designed with the idea of keeping the working set small will have a performance advantage.
With this in mind, it would seem that whether to have a large auto object or not is an issue which has pros and cons on both sides, that is, there is no canonical answer to this question.