I think it's important not to take Tim's point about performance too lightly here. There are some key interfaces between components that can't afford the overhead of a function call, let alone an indirect call via a function pointer.
Three instances that come to mind are: - Allocation. For best performance, the common case of a new() needs to be inlined directly into the compiled code. - Write barrier (and read barrier if we need one). The common case of a write barrier should be a handful of instructions. - Yield points. Again should inline down to a couple of instructions. I'd be interested in any approaches you may have thought of for these interfaces. On Mon, 2005-09-19 at 19:46 +0200, David Tanzer wrote: > Today I have added some additional Information to the Wiki page. > > We should also consider using C++ and abstract classes to maintain our > component model. While this would make inter-component communication > slightly slower it would be easier to maintain. We should also think > about using an existing component model like OSGi. > > The model I posted provides pretty fast communication between components > without sacrificing too much flexibility, but it is maybe not as easy to > maintain as a clean, object-oriented implementation (i.e. C++). We could > discuss how important these aspects are to us, i.e. how much runtime > efficiency we are willing to sacrifice for maintainability and > flexibility and vice-versa. First order of priority, IMO, is to decide what are the performance critical components, and what are not. For the infrequent cases, we can afford a heavy-weight approach, for those that happen every few bytecodes, we need to be lean and mean. cheers Robin
