Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Standardize facelift dbus communication #303
base: master
Are you sure you want to change the base?
Standardize facelift dbus communication #303
Changes from 8 commits
d451419
47b4a42
3c8f9ad
3d385a1
7fb1d9c
698e225
2cf600d
a3e6151
10557c3
3ed6fe9
92e7677
277b7e5
73c9a06
8e122fb
33b996d
8e2bd56
adcce61
b359770
1d94e76
1e5ab12
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI, the construct you broke here is meant to provide a way for that generated code to be usable with both an IPC transport channel where method IDs are strings (such as DBus), and an IPC where method IDs are integer (such as the the current "local" IPC, and the hi-performance IPC which I have been working on). Using integers instead of strings is obviously more efficient.
Your change will make the introduction of a new IPC harder.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we please stop the "performance" discussion? now you are discussing about "future possible performance degrades with some not in-place high performance IPC!!!".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The local IPC uses integer IDs, so we are not talking about the future.. The current approach should work with your changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The performance claims needs to be backed up by actuall KPI measurement
There "Local" version AFAIK uses internal Qt signal/slots so we can't have seriously a discussion over difference of treating a signal with integer and a signal with string!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no doubt that sending an integer (which does not even need to be wider than 8 bits) is faster than sending a multi-character string. Also, string comparisons are not free, so the processing of an incoming request is also faster if an integer is used as method ID since no comparison is even needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A simple benchmark of signal 30 character long being emitted/received 10000 times shows followings:
https://github.com/idleroamer/facelift/tree/feature/benchmark_local_signals
Current implementation
Signal emission/receive duration: 1463 ms
Current PR:
Signal emission/receive duration:1102 ms
A signal name comparison is not a bottleneck.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do those figures tell us that using a string is faster than using an integer ?
The reason why integers can be used is not really because using strings has been identified as a performance hotspot, but rather that it is necessary for IPCs which use integers as messageID. I do not understand why your change has to break that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, those figures tell us whether we send MessageIDs as strings or as integers is not a performance bottleneck.
It as well tells us performance arguments without benchmarks has no values.
I appreciate your time but I have the feeling you even haven't looked at the PR? the "sendSetterCall" is internal call between IPCProxy and Local/DBusIPCProxyBinder and using integers is simply superfluous
You had performance claims now you are talking again about some IPC which is not even there yet AGAIN.
Please let me know if you personally hold this PR against your views/plan for facelift so I don't take your time anymore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a misunderstanding here.
How about having a call tomorrow afternoon ? I guess we could use google meet for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is a fine suggestion. Though tomorrow is a little tight in the afternoon, so let me know if tomorrow morning or the Friday's afternoon fits your calendar, otherwise we postpone to next week.