> The recommendation is not necessarily to kill the performance by going for > overkill with a mutex_t object protecting the reference count. Most > platforms provide some form of efficient atomic operations. Win32 has the > InterlockedXXX range of functions, and platforms such as SPARC provide > support for it in the hardware, so that it is possible to write efficient > atomic increment, decrement and swap functions that do not rely on using a > mutex object (see STLport for an example). (can't speak for other > platforms).
Well, you've only named two of the many platforms Xerces supports. And looking at the Xerces' current platform-specific code for Solaris you'll find the atomic increment/decrement is done use a mutex. In fact, most of the supported platforms work this way. > Our (server) application makes HEAVY use of thread safe reference counted > objects and we can usually max out the CPU on a quad processor box with > enough load. We have not seen any serious contention problems when reference > counting is implemented properly. My experience is different from yours. > Also, it seems that the proposal being played with involves having the > existing IDOM interface be the default interface with a few 'smart pointer' > classes which would be doing most of the work for reference counting. > > This seems to suggest that code wishing to refrain from unnecessary usage of > the ref counting mechanism could use the raw interfaces and would never hit > the incrCont() and decrCount() methods, hence avoiding the penalty? If someone wants implement non-intrusive, I'm all for that. > Yes, integer incrememnts/decrements are not free, but then neither are > virtual function calls. So it's a usability vs. performance question, as > with everything else. Are virtual tables really that terrible a price to pay > for all the (mostly) error-free behavior they buy you? Similarly, is a > little bit of extra code (i.e. two simple methods), and a little bit of > memory (4 bytes per Node object), really that bad of a price to pay for > adding an extremely usable interface to the xerces DOM with automatic memory > management etc. etc.? In our case it is. We never modify documents, but we reference lots of nodes. I tested our performance with the old DOM where I commented out just the increments and decrements of the reference counting. On some of our sample inputs, we got a 15% increase in performance, so we were paying a 15% penalty for _no_ increase in usability for our application. Profiling in Visual Quantify confirmed the results. I find your analogy of virtual functions to be specious. When I design a class, I can make the choice whether or not I want to use virtual functions. This new reference-counting of the Xerces IDOM is intrusive -- I _must_ pay the penalty whether or not I care about making the interface more "usable." And yes, 4 bytes per node (plus any additional padding alignment required) is a high price to pay when you have may large documents. Finally, I have no doubt that the overhead of an atomic increment instruction is much greater than that of a virtual function call. Dave --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
