Re: [xml] libxml2 thread safety

["Jon Smirl" <jonsmirl mediaone net>]

There is a research paper from someone at IBM who analyzed the whole mess
but I don't know if it is on-line any more. Bottom line was for Windows and
Linux a non-thread safe DOM was in the order of 20x faster than a
thread-safe one on SMP machines.  The non-thread safe one is always going to
be faster; it doesn't call any lock code. There is also a major performance
difference between a single thread alloc and a multi-thread one and DOM code
loves to do allocs.

Xerces and Xalan work fine in multithreaded environment. They do this by
handling threading at a very high level. In fact their compiled XSLT sheets
can even be shared between threads since they have been designed to be
read-only. My code using these has very few locks, initialization and
insertion of a compiled XLST sheet into the shared pool.

Personally I have written an app which used a thread-safe DOM and allowed
multiple threads into the DOM at once. It was a major mistake and took
forever to debug. It is much smarter to lock the DOM with a single global
lock. Globally locking the DOM would also probably have resulted in faster
execution of my app but we never measured it. The next step down the
thread-safe DOM path is thread-safe strings and those are even worse.

Jon Smirl
jonsmirl mediaone net