bus: use va_marshaller to avoid GValue boxing#2683
Conversation
fujiwarat
left a comment
fujiwarat
left a comment
There was a problem hiding this comment.
Thank you very much for your patch.
I noticed the comment in glib/gobject/gsignal.c:g_signal_new() explains g_signal_set_va_marshaller(). and confirmed the patch can switch to use the va_marshaller.
Not only do va_marshallers allow you to avoid the GValue boxing, it allows you to also get better profiling data at runtime.
I guess the GValue boxing means instance_and_params in glib//gobject/gsignal.c:signal_emit_valist_unlocked() and it might effects the memory usage of ibus-daemon?
I'm not sure about where effects the better profiling data.
It would be great if you rebase the patch and add the BUG=https://github.com/ibus/ibus/pull/2683 line at the last of your patch description.
I will test your patch as Fedora internal patch.
I wouldn't expect any difference to memory usage.
By using the va_marshaller you can collect the values from the call site and directly call the signal handler using the default calling convention without any sort of FFI trampoline. Where that helps with profiling is that you'll get a proper callstack that the Linux kernel's perf subsystem can unwind.
Sure thing |
Building your own marshaller list is most of the way there to get better signal performance, but you can go a bit further by having it generate va_marshallers and set those too. Not only do va_marshallers allow you to avoid the GValue boxing, it allows you to also get better profiling data at runtime. BUG=ibus#2683
|
LGTM. Merged.
Sorry, I meant to reduce the times of the memory allocation and enhance the performance.
Thank you. I will learn it later. |
Building your own marshaller list is most of the way there to get better signal performance, but you can go a bit further by having it generate va_marshallers and set those too. Not only do va_marshallers allow you to avoid the GValue boxing, it allows you to also get better profiling data at runtime. Fixes: ibus@c13c54e BUG=ibus#2683
|
Applying another patch for 1.5.32 above. |
Building your own marshaller list is most of the way there to get better signal performance, but you can go a bit further by having it generate va_marshallers and set those too. Not only do va_marshallers allow you to avoid the GValue boxing, it allows you to also get better profiling data at runtime. Fixes: ibus@c13c54e BUG=ibus#2683
Building your own marshaller list is most of the way there to get better signal performance, but you can go a bit further by having it generate va_marshallers and set those too. Not only do va_marshallers allow you to avoid the GValue boxing, it allows you to also get better profiling data at runtime. Fixes: ibus@c13c54e BUG=ibus#2683
Building your own marshaller list is most of the way there to get better signal performance, but you can go a bit further by having it generate va_marshallers and set those too. Not only do va_marshallers allow you to avoid the GValue boxing, it allows you to also get better profiling data at runtime. Fixes: ibus@c13c54e BUG=ibus#2683
Building your own marshaller list is most of the way there to get better signal performance, but you can go a bit further by having it generate va_marshallers and set those too. Not only do va_marshallers allow you to avoid the GValue boxing, it allows you to also get better profiling data at runtime. Fixes: c13c54e BUG=#2683
2 participants
Building your own marshaller list is most of the way there to get better signal performance, but you can go a bit further by having it generate va_marshallers and set those too.
Not only do va_marshallers allow you to avoid the GValue boxing, it allows you to also get better profiling data at runtime.