alloc_link, pthread mutex locks, malloc and performance

[Andrew Marlow]

Hello dbus guys,

I am new to dbus and need some help please. I have some performance
concerns about a dbus app I am working on.

callgrind indicates that many posix mutex locks are being taken on the
server side during message validation. These calls are in alloc_link
(and the corresponding call to free_link). I did a temporary hack to
these functions, making them use malloc and free instead. This caused
the mutex locks to drop off the radar (hurrah!) but it also caused
malloc to feature much higher in the costs (boo!).

I know that the code is the way it is because originally the cost of
lots of small allocates via direct calls to malloc was found to be
expensive. Heap fragmentation springs to mind. This was solved using a
memory pool which was later made thread-safe by adding the locks. So
going back to direct malloc is only an experimental hack. I am not
proposing that this is done officially. Indeed, my profile results
demonstrate that the repeated allocates are an issue. But I have a few
thoughts about how to deal with this issue that I want to discuss in
this mailinglist.

First, has anyone looked at replacing the memory pool with a more
efficient allocator than malloc? I came across one called nedmalloc, at
http://www.nedprod.com/programs/portable/nedmalloc. This seems to
compare very favourably with hoard but with a more permissive license.
Has anyone tried that? What do people think?

Second, I notice from my callgrind results that the memory pool is used
extensively during message validation. Would it not be possible to
change the message validation so it used its own memory management. A
validation memory management package might still use a memory pool but
might also take a parameter to say whether or not to lock the pool. I am
just guessing here, since I dont know enough about the dbus code, but I
am wondering about specifying such a flag in my server since I know my
server is single-threaded. Maybe there should be a set flag routine that
a server can call during initialisation that says whether or not it is
single-threaded. What do people think about this please?

Third, a hybrid approach could be used. alloc_link could continue to use
the memory pool but the pool could employ a flag that controls whether
or not it locks the pool. Single threaded servers can set this flag to
false. This is slightly more dangerous because it assumes that a
single-threaded server will not have any threads started behind the dbus
scenes that calls alloc_link.

--
Regards,

Andrew Marlow

This transmission contains information that may be confidential and contain personal views which are not necessarily those of YouView TV Ltd. YouView TV Ltd (Co No:7308805) is a limited liability company registered in England and Wales with its registered address at B6, Ground Floor Broadcast Centre, 201 Wood Lane, London, UK, W12 7TP.

For details see our web site at http://www.youview.com.