From freedesktop-dbus Wed Nov 05 13:41:42 2008 From: "Jerome Philbert" Date: Wed, 05 Nov 2008 13:41:42 +0000 To: freedesktop-dbus Subject: Re: About performance of D-Bus Message-Id: <9c0d19af0811050541q1f2b5bd4o8cf15323da4b4bf1 () mail ! gmail ! com> X-MARC-Message: https://marc.info/?l=freedesktop-dbus&m=122589250811580 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0816078248==" --===============0816078248== Content-Type: multipart/alternative; boundary="----=_Part_6340_25254890.1225892502241" ------=_Part_6340_25254890.1225892502241 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 > Hi, > > On Tue, Nov 4, 2008 at 6:09 AM, Jerome Philbert > 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 > ------=_Part_6340_25254890.1225892502241 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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

------=_Part_6340_25254890.1225892502241-- --===============0816078248== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dbus mailing list dbus@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dbus --===============0816078248==--