Re: [xml] First experiments with threading

[Daniel Veillard <veillard redhat com>]

On Mon, Oct 15, 2001 at 12:59:16PM +0100, Gary Pennington wrote:
> Daniel Veillard wrote:
> >  I made the tests on an SMP box running Linux Red Hat with 2.4.7 kernel.
> > I think the impact comes from the access to the memory routines, libxml
> > is extremely aggressive on the memory allocator, and in the current code
> > the xmlMalloc/xmlRealloc/xmlFree are part of the per-thread data. This
> > mean that we are currently calling pthread_self() in addition to the
> > existing routine each time we access them and this reflects on performances.

  Made more tests, the problem is not with pthread_self() or the call to
__xmlFree() or __xmlMalloc() but seems rather due to significant performance
penalties when compiling with -D_REENTRANT

> On Solaris 8, I'm seeing a different picture.
>
> I've run the version built with the patches I submitted against 2.4.5 
> and I see a 12/12% degradation. You are showing 57/46%, which is a lot 
> higher and also not a consistent degradation.

  Well the fact that the multi-threaded allocator is slower is not surprizing,
it's really fast usually, and the associated work needed for -D_REENTRANT
can have a significant impact.
  The fact that --valid make serious changes is not surprizing either
the working set of syscalls made is really affected, having different
degradation impact for both modes is not surprizing.
  Also could you check the CVS version ?

> I guess that this could be down to the difference between the 
> Solaris/Linux threading models or it could be partly as a result of 
> changes in the code above and beyond the patches I submitted.

 yes, I bet on the 1st one since I mostly did name changes but not
mechanism changes

> I think that to make sure we are comparing like with like, I should 
> build against your modifications. Is there a CVS incantation that I can 
> use to pull down the same code that you tested with or can I just get 
> the latest code from the cvs repository?

  latest from this night will do.

> >  My current view are:
> >   1/ that threaded mode should not be the default configuration
> I agree. Lost of people don't need thread support and would rather not 
> pay the performance price (which will always exist no matter how much we 
> try to minimize it).

  okay

> >   2/ that by default xmlMalloc/xmlRealloc/xmlFree should be kept
> >      application wide settings
> This might be wise anyway, since a thread passing a memory pointer to 
> another thread may have problems if the memory allocator used by each 
> thread is significantly different.

  agreed too, that can get really messy.

> >   3/ that it shall be relatively straightforward to make them
> >      thread specific with the use of a dedicated #define
> >      this can still be useful for other thread models the
> >      equivalent of pthread_self() is real cheap.
> The code is already written. Could you make it configurable option for 
> the brave of heart?

  Done, configure now lists:
      --with-thread-alloc  Add per-thread memory(off)

> >  I will work on 2/ to check if my analysis of the added cost was right,

  I was wrong,

> > and will do 3/ if it is confirmed. Then I will cleanup the couple of places
> > where libxml code need locking and add some threading regression tests.

  I did 3/

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard redhat com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/