I know that some tools can add noticable startup time, but I don't know if it's due to bytecode compiling or bad code. I have encountered memory leaks due to non-collected viewbuilder objects though. You can get a tools memory usage by using collectgarbage (google).
I have been manipulating the code of my last tool checking the use of memory with collectgarbabe. I have come to the following conclusion:
I can build the tool in 2 ways (I've already checked):
1- The first loads all ViewVuilder functions and objects in memory, since the Renoise boot, and stays there all the time. In this way, it is possible to easily use the IDs of each object to manipulate it. In this way, it is possible to close the tool and reopen it and do not lose "the state" of the object. This approach makes my tool return about 2800KB with collectgarbage. But, it has two advantages. The first is once loaded in memory, always going very fast. The second is that it does not lose the state of each object. Here I use globals and locals to define the objects (without wrapping them in a function).
2- The second way is by wrapping each object definition within a function, which ends with the return of the object. Collectgarbaje returns about 750KB, a saving of about 2MB. However, the typical error of ID already registered appears, and before loading each object I have to force to equal each identifier = nil. This solves the problem, but it has a drawback. The tool loses the status of the object when it is closed. Since the tool has a multitude of controls, it is not desirable to lose the configuration of each object. I do not know if there is any way to avoid the ID error already registered and that the tool keeps the "state of the objects" after closing it and reopening it again, because I put the id = nil in each object.
On the other hand, I have done collectgarbaje tests with other tools. For example, Duplex returns 18688.289 KBytes (approximately 18.6MB). VoiceRunner 1437.452KB (1.43MB). If a tool generates <20MB, it seems reasonable. From 1 to 5MB it seems a pretty low figure.
On the other hand, a tiny delay when loading Renoise is acceptable if after, the tool is loaded very fast (to open it). In the first case, the tool is executed instantaneously, since everything is loaded in the memory. The second case, there is a slight initial delay. Then, I come to the conclusion that it is convenient to use the memory depending on the use of the tool. If each time you start the tool you have to have an identical object state, the second option is appropriate. If you intend to keep the state of the objects for the duration of the entire Renoise open session, the first option is better.
I need to define with many ID's a multitude of objects, in order to change their state (color, bitmap, text, etc.). Then it is not advisable to cancel the id previously to reload it again. So I do not know how to merge the two cases, so collectgarbaje return the minimum amount possible (I think it will be around 500KB) and at the same time do not lose the state of the objects when closing and reopening the tool in the same session of Renoise.
All this is a little messy for me yet...