From freedesktop-dbus Fri Oct 31 13:22:00 2008 From: "Havoc Pennington" Date: Fri, 31 Oct 2008 13:22:00 +0000 To: freedesktop-dbus Subject: Re: About performance of D-Bus Message-Id: <2cef5bf40810310622u22efee18ob4601bf0a1867320 () mail ! gmail ! com> X-MARC-Message: https://marc.info/?l=freedesktop-dbus&m=122545932706869 Hi, On Fri, Oct 31, 2008 at 9:15 AM, Havoc Pennington wrote: > I am not saying that dbus is only 2% of the time; maybe on your > embedded device it is more time. I don't know. But you should profile > this before you bother trying to improve dbus. Because if dbus is 2% > of the time, you should work on the other 98%, not on dbus. > And the other point is to look at how dbus is used. If dbus is 50% of the time for some user action, there's a good chance you are using dbus in a bad way, e.g. making dozens of round-trip calls to implement a single user action. Doubling dbus speed could get you from 50% of the user action spent in dbus, to 25% of the user action spent in dbus. But fixing how dbus is used, e.g. removing the misdesigned round-trip-requiring APIs, could get you from 50% of user experience time in dbus, to 1% of user experience time spent in dbus. Which is a much bigger win. The bottom line is that there just aren't that many real world contexts where the time it takes to make a dbus method call is any kind of bottleneck. You have to make 1000 method calls to create a bottleneck, not 1. So, frequently, optimization involves reducing the number of calls, not making the calls faster. Once again, I am not *against* optimizing dbus. Please give it a shot. I am just trying to be helpful - if you have an actual *product* with a user experience that covers a lot of non-dbus stuff, you should not spend your time optimizing dbus unless you *know* dbus is the problem. Havoc _______________________________________________ dbus mailing list dbus@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dbus