101–110 of 209 posts
For a more in-depth performance discussion of dbus, check out http://lists.freedesktop.org/archives/dbus/2012-March/015024...
Above noted on linux-kernel here: http://thread.gmane.org/gmane.linux.kernel/1930358/focus=193...
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…
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. The code is several times longer than it otherwise would be due to all the function declarations...
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).
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 of my former coworkers to contact me with concerns about DBus. We used it pretty heavily.
As for DBus itself: guys, it is useful. It works. You can count on it being there and working in most distributions, you can talk to most things nowadays. Its easy to use (for most use cases), language bindings are everywhere.
So, turns out is slow. It's so cool that we have identified that. Let's fix it.
Even if the slowness doesn't seem to bother many of its use cases.
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.
Earlier quoted context omitted.
Nothing obvious about it. If you look at the Linus's trace, it's all heap and mutex operations. That's just sloppy internal design full of concurrency bottlenecks and lots of in-memory cloning. You certainly don't mean to imply that both are the only way to implement a "security policy driven message bus" software, do you?
> If you look at the Linus's trace, it's all heap and mutex operations. That's just sloppy internal design full of concurrency bottlenecks and lots of in-memory cloning. Far from it. One of the core designs of kbus (which dbus cannot do because it's not in the kernel) is that you can seal the payload buffer from the sender so the receiver and use it safely concurrently without having to clone anything. There is obvio…
Earlier quoted context omitted.
I agree, the OP title is a bit misleading. I use dbus every day on my laptop and it works totally fine - I don't notice its existence. I'm all for improvements, but I'm quite patient and quite happy to wait this one out.
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…
Well, it wasn't really DBus' fault then, was it?
Earlier quoted context omitted.
> Indeed. I just use shm_open()+mmap(MAP_SHARED) and go about sharing my data between processes, and have had no problems whatsoever. Then throw in sem_open() so only one process is locking the data at a time. Wrap all that in a 2KB header and it's trivial to use in any project. Is that sarcasm, or you don't know what dbus is used for?
> Is that sarcasm, or you don't know what dbus is used for? I know what it's used for in the desktop application space; but you might want to ask the authors of Xfce components like Mousepad that make their software rely on it for simple tasks like reusing an existing window when opening a file. Because I'd sure like to be able to run my Xfce desktop with D-Bus off in FreeBSD. "D-Bus is a message bus system, a simple…
The whole idea is the "standard" part, not merely the "talk to each other part".
Reason for getting kdbus into kernel, and not a generic ipc but specifically kdbus, is because user space that depends on dbus will continue to work with kdbus.
What I still don't understand is, what is the point of keeping compatibility of currently non-existing userspace, if software that depend on dbus right now doesn't need performance enhancements and can just keep using regular dbus, and software that need high performance bus doesn't even use dbus since it's slow? Under these circumstances, why they insist on making kdbus strictly a dbus implementation but not a more generic ipc mechanism?
Earlier quoted context omitted.
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.
You don't fling uncompressed video between apps like that, it goes straight to the hardware-accelerated h.264 (or whatever) encoder and then a low bandwidth stream comes out. Local AF_UNIX sockets (aka userspace dbus) provide ample bandwidth for that use case.
Earlier quoted context omitted.
You do realize that pretty much whole of Windows is, underneath, based on COM, including most of the .Net-exposed system API's? I'll agree that COM and DCOM are... hairy, if you're implementing COM objects 'by hand'. But there's a reason for all of it, and I have yet to see an easier and more flexible way to write cross-language components. I could write a COM object in C++, call it from VBScript in a very simple com…
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…
KDE has KParts and GNOME has Bonobo. The latter is apparently deprecated, but it used to be used by the desktop panel for embedding widgets running in separate processes.