81–90 of 209 posts
Earlier quoted context omitted.
IIRC the use case is to stream media over DBus, which currently no one is doing because it is too slow.
So: if DBus was suddenly fast enough to stream media over, what applications would be using this feature, for what sets of streaming endpoints?
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 sort of works, on Windows, when when one or preferably both sides of the connecting components are made by Microsoft. You never see non-Microsoft code talking to non-Microsoft code from a different vendor via COM. This is not a successful component interface standard.
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…
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…
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…
a) This is the output of perf top, a system-wide trace of the last few seconds
b) The application uses lots of library functions
c) Due to lots of locking in the application, the cpu doesn't spend much time in the app itself
To find out which high-level functions (that in turn call library functions) take the most time, use perf record to get call stacks.
What's potato, as said in the mailing list?
http://www.urbandictionary.com/define.php?term=potato&defid=...
Earlier quoted context omitted.
You can probably find it here: https://wiki.freedesktop.org/www/Software/dbus/
Is there a paper/article that discusses and categorizes the differences between IPC mechanism? Their pros and cons etc. What mechanisms are there? What is used on Windows? OS X/iOS? QNX? BeOS? Android? Solaris? etc. The Wikipedia article on IPC https://en.wikipedia.org/wiki/Inter-process_communication is really incomplete.
What's potato, as said in the mailing list?
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.
That was my first reaction as well. But to be fair, the kdbus people always said the real speedup will be seen for large packets. However, the real issue is how slow overall DBus seems to be according to those numbers. As Linus says earlier in the thread: "No way should it take 4+ seconds to send a 1000b message to back and forth 20k times." This is indeed rather shocking.