Re: [xml] First experiments with threading

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).


  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 Veillard      | Red Hat Network
veillard redhat com  | libxml Gnome XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]