[prev in list] [next in list] [prev in thread] [next in thread]
List: freedesktop-dbus
Subject: Re: About performance of D-Bus
From: "Jerome Philbert" <jerome.philbert () gmail ! com>
Date: 2008-11-05 13:41:42
Message-ID: 9c0d19af0811050541q1f2b5bd4o8cf15323da4b4bf1 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Thanks again for your analysis, Havoc.
Finally, your suggestions for optimizing speed, consist in removing security
and check from DBus, what is contrary to the interest of D-Bus, especially
if it is designed for an open platform.
But I cannot have both speed and security :-)
I think I have also tried your suggestions number 3 and 4.
Is not it equivalent to:
- remove paranoid validation ? (by using
DBUS_VALIDATION_MODE_WE_TRUST_THIS_DATA_ABSOLUTELY in the code)
- build D-Bus with disable-checks option ?
In this way, I have measured that D-Bus was 7% faster.
Jerome
2008/11/4 Havoc Pennington <hp@pobox.com>
> Hi,
>
> On Tue, Nov 4, 2008 at 6:09 AM, Jerome Philbert
> <jerome.philbert@gmail.com> wrote:
> > 100ms / 4.7ms = 21 messages only
> > Moreover, this is the ideal case where the CPU has nothing else to do
> than
> > sending messages ...
> > In the reality, the CPU has lots'of things to do, so I could never send
> up
> > to 21 messages.
> >
>
> On a CPU this slow, it isn't clear that libdbus is remotely usable;
> you may need a dbus implementation (or other ipc system) that is
> making different tradeoffs in the direction of efficiency. Or
> worst-case, you may need to figure out how to avoid some of the ipc.
>
> If you made a dbus library that:
> * always blocked, thus eliminating the need to build DBusMessage
> objects or maintain a message queue or deal with main loop
> * was not thread-safe, thus eliminating locking
> * was not robust against hostile peers, thus eliminating message validation
> * did not ever do checks like dbus_return_if_fail thus eliminating more
> code
> * was not safe against out-of-memory, thus eliminating even more code
> * did not try to "multiplex" code modules with "path registration" or
> "handler registration", thus killing more code and overhead
>
> I think you could have a library that was dramatically smaller and
> faster, fwiw. Basically by making it much less flexible and robust,
> and just being careful about using it. I believe an implementation of
> dbus could be pretty close to raw socket speed by making tradeoffs
> like the above.
>
> Current libdbus I'm sure can be made 30% faster or 40% faster or
> something like that, given enough effort, but if you are only getting
> 21 messages now, then even a 100% speedup would only get you to 42
> messages. If that still won't be enough, I would not dive into libdbus
> optimization, I would figure out how to somehow use dbus less.
>
> Again, we'd definitely love to see someone work on making current
> libdbus faster.
>
> Havoc
>
[Attachment #5 (text/html)]
Thanks again for your analysis, Havoc.<br><br>Finally, your suggestions for \
optimizing speed, consist in removing security and check from DBus, what is contrary \
to the interest of D-Bus, especially if it is designed for an open platform.<br> But \
I cannot have both speed and security :-)<br><br>I think I have also tried your \
suggestions number 3 and 4.<br>Is not it equivalent to:<br>- remove paranoid \
validation ? (by using DBUS_VALIDATION_MODE_WE_TRUST_THIS_DATA_ABSOLUTELY in the \
code)<br>
- build D-Bus with disable-checks option ?<br>In this way, I have measured that D-Bus \
was 7% faster.<br><br>Jerome<br><br><br><div class="gmail_quote">2008/11/4 Havoc \
Pennington <span dir="ltr"><<a href="mailto:hp@pobox.com" \
target="_blank">hp@pobox.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); \
margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi,<br> <div><br>
On Tue, Nov 4, 2008 at 6:09 AM, Jerome Philbert<br>
<<a href="mailto:jerome.philbert@gmail.com" \
target="_blank">jerome.philbert@gmail.com</a>> wrote:<br> > 100ms / 4.7ms = 21 \
messages only<br> > Moreover, this is the ideal case where the CPU has nothing \
else to do than<br> > sending messages ...<br>
> In the reality, the CPU has lots'of things to do, so I could never send \
up<br> > to 21 messages.<br>
><br>
<br>
</div>On a CPU this slow, it isn't clear that libdbus is remotely usable;<br>
you may need a dbus implementation (or other ipc system) that is<br>
making different tradeoffs in the direction of efficiency. Or<br>
worst-case, you may need to figure out how to avoid some of the ipc.<br>
<br>
If you made a dbus library that:<br>
* always blocked, thus eliminating the need to build DBusMessage<br>
objects or maintain a message queue or deal with main loop<br>
* was not thread-safe, thus eliminating locking<br>
* was not robust against hostile peers, thus eliminating message validation<br>
* did not ever do checks like dbus_return_if_fail thus eliminating more code<br>
* was not safe against out-of-memory, thus eliminating even more code<br>
* did not try to "multiplex" code modules with "path \
registration" or<br> "handler registration", thus killing more code \
and overhead<br> <br>
I think you could have a library that was dramatically smaller and<br>
faster, fwiw. Basically by making it much less flexible and robust,<br>
and just being careful about using it. I believe an implementation of<br>
dbus could be pretty close to raw socket speed by making tradeoffs<br>
like the above.<br>
<br>
Current libdbus I'm sure can be made 30% faster or 40% faster or<br>
something like that, given enough effort, but if you are only getting<br>
21 messages now, then even a 100% speedup would only get you to 42<br>
messages. If that still won't be enough, I would not dive into libdbus<br>
optimization, I would figure out how to somehow use dbus less.<br>
<br>
Again, we'd definitely love to see someone work on making current<br>
libdbus faster.<br>
<font color="#888888"><br>
Havoc<br>
</font></blockquote></div><br>
_______________________________________________
dbus mailing list
dbus@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dbus
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic