Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“DBus is seriously screwed up”

thread.gmane.org

Post reply on HN
Print view View original

111–120 of 209 posts

Re: “DBus is seriously screwed up”

#111

Post by hp »

riking wrote: post #20
vidoc wrote: post #13

It all started with a microbenchmark: http://thread.gmane.org/gmane.linux.kernel/1930358/focus=193... DBUS implementation aside (which seems to leave a lot of room for optimization), my initial reaction was that the gain was rather minimal compared to the claims of the systemd folks.

So, basically, systemd-bus would solve the problems even without kdbus, if it avoided all the extraneous memory allocations.

kdbus really addresses a different performance issue than tuning mallocs and locks would. By tuning mallocs/locks/validation/parsing, you can reduce the overhead of each dbus send/receive, but with kdbus you remove half of the send/receives. So however fast your sends/receives are, kdbus will still make things faster by not doing as many of them.

Re: “DBus is seriously screwed up”

#112

Post by m0th87 »

outworlder wrote: post #103

This whole pulling crap out of the Linux kernel mailing list is doing the industry a disservice. Quotes are taken out of context, used by people who lack the required technical understanding, which then reach the ears of managers, who will promptly act on overblown concerns. All of it somehow backed by Linus' word, even when he doesn't actually mean it. I've started a stopwatch to see how long it will take for some o…

What's being taken out of context here? It seems the conversation is about dbus being slow, and you agree that it is?

Re: “DBus is seriously screwed up”

#113

Post by tcfunk »

m0th87 wrote: post #112
outworlder wrote: post #103

This whole pulling crap out of the Linux kernel mailing list is doing the industry a disservice. Quotes are taken out of context, used by people who lack the required technical understanding, which then reach the ears of managers, who will promptly act on overblown concerns. All of it somehow backed by Linus' word, even when he doesn't actually mean it. I've started a stopwatch to see how long it will take for some o…

What's being taken out of context here? It seems the conversation is about dbus being slow, and you agree that it is?

Probably referring to the link title, which could imply quite a bit more than it simply being slow.

Re: “DBus is seriously screwed up”

#114

Post by _pmf_ »

yoklov wrote: post #102
userbinator wrote: post #51

I can make two observations and hypotheses from the profiling results, which agree with Linus' conclusion of "bad user-level code": - Memory allocation/deallocation are taking the most time. - All the percentages for each function are very small. The former is a characteristic of code which heavily abuses dynamic allocation. It's surprising to see how many programmers are not aware of the overhead it adds and would m…

Frequently the second problem is exacerbated by cache misses. Every operation becomes (much!) slower, but nothing stands out. Not a popular opinion here, but excessive modularity like that is practically the definition of bad, hard to follow code though IMO. Ignoring performance issues, everything happens somewhere else, and large changes now take several times longer, since the changes are not local to a function. T…

> Its a nightmare. It tends to be the kind of code you feel productive while writing ("I'm cleaning up this 200 line function"), but is really just making the codebase worse (is there a general term for this kind of false productivity? It's a common problem I see).

This issue is pervasive when Desktop/Web developers try to improve embedded software. I've achieved a thousandfold increase in performance by converting an embedded data logger from using printf to using a dedicated formatting function (most of the time was spent on parsing the format string and performing allocations).

Re: “DBus is seriously screwed up”

#115

Post by reidrac »

outworlder wrote: post #106
reidrac wrote: post #15

Earlier quoted context omitted.

I made a silly desktop app some time ago and it used DBUS to get notifications from NetworkMonitor when the system went online/offline. Nothing too fancy, very few lines of code. When I was implementing that, I managed to get several segfaults from my Python code. All together seemed a little bit fragile to me :( That was 5 years ago, things are probably better now (to be fair, I don't know what was causing the crash…

> When I was implementing that, I managed to get several segfaults from my Python code Well, it wasn't really DBus' fault then, was it?

I didn't mean to say my Python code was the one crashing with a segfault. Apologies if my comment wasn't clear enough.

I just did a search in my bugzilla account at Red Hat (Fedora distro) but I couldn't find a report for that specific crash. The closest I can find is a report on a crash of notification-daemon (could be related though, as it uses DBUS to advertise a service).

I'm surprised I didn't file a bug report, but there you are.

Re: “DBus is seriously screwed up”

#116

Post by TheCondor »

Zardoz84 wrote: post #84
72deluxe wrote: post #41

Earlier quoted context omitted.

COM is indeed an interesting beast and very useful. Being able to integrate other programs into yours, relying on COM to do so is very helpful. I don't know of a way on Linux or OSX to embed a word processor to work on documents but never show the user (but this might be due to my lack of knowledge about those systems - I would welcome being enlightened). I once wrote something that processed a plethora of Word docum…

Check what does KDE. For example, KDevelop uses Kate as internal text editor.

I believe that is currently called kparts. Both gnome and kde had corba models early on and looked to be following the OpenDoc model. I think both orbit and Mico are now orphans. They seemed to scale it all back and pivot. I think people want widgets with behavior, not full blown browsers and word processor components.

Re: “DBus is seriously screwed up”

#117

Post by reidrac »

belorn wrote: post #44
reidrac wrote: post #15

Earlier quoted context omitted.

I made a silly desktop app some time ago and it used DBUS to get notifications from NetworkMonitor when the system went online/offline. Nothing too fancy, very few lines of code. When I was implementing that, I managed to get several segfaults from my Python code. All together seemed a little bit fragile to me :( That was 5 years ago, things are probably better now (to be fair, I don't know what was causing the crash…

Were you using threads? Python really should not crash, but combine it with library imports implemented in c and threads, and you get really subtle race conditions which result in segfaults. I have myself been force to debug why Python segfaulted, and it was a standard library call which internally used threading, and that caused a conflict with a c library that was not threading safe.

Sorry, it wasn't Python. It was a system component that crashed as consequence of my Python code using DBUS.

Re: “DBus is seriously screwed up”

#118

Post by hp »

hp wrote: post #111
riking wrote: post #20

Earlier quoted context omitted.

So, basically, systemd-bus would solve the problems even without kdbus, if it avoided all the extraneous memory allocations.

kdbus really addresses a different performance issue than tuning mallocs and locks would. By tuning mallocs/locks/validation/parsing, you can reduce the overhead of each dbus send/receive, but with kdbus you remove half of the send/receives. So however fast your sends/receives are, kdbus will still make things faster by not doing as many of them.

Here is the long version of that point: http://article.gmane.org/gmane.linux.kernel/1939651

Re: “DBus is seriously screwed up”

#119

Post by hp »

lmedinas wrote: post #12

Another great Linus quote: "The people who talk about how kdbus improves performance are just full of sh*t." http://thread.gmane.org/gmane.linux.kernel/1930358/focus=193...

Linus is mixing together two different performance issues.

http://article.gmane.org/gmane.linux.kernel/1939651

kdbus is solving an "architecture" issue that would affect any binding, while his profile is essentially of the gdbus binding.

Re: “DBus is seriously screwed up”

#120

Post by jschwartzi »

scrollaway wrote: post #62
semi-extrinsic wrote: post #39

Earlier quoted context omitted.

So: if DBus was suddenly fast enough to stream media over, what applications would be using this feature, for what sets of streaming endpoints?

KDBus was designed with sandboxed applications in mind. So use-case wise think android-style "use the camera app to take a picture/video", where the camera app transfers the media to another app over kdbus, thus without leaking information about the system.

If the point is to have Android style IPC, why not just pull a version of Binder into the mainline kernel?
Post reply on HN