This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Implementing a generic binary trace interface.
hunt wrote:
> [...]
> > That's still orders of magnitude higher than a single binary
> > assignment.
>
> Yes. It appears to be the buffer reservation and manipulation that is
> expensive. [...]
Please explain why you think so ("the"). Others have observed that
kernel vscnprintf is a problem too.
In any case, I don't like the binary tracing idea only because it does
away with some of the buffering/copying of the formatted output. It's
because it eliminates run-time conditionals (interpreting of
formatting directives) and unnecessary copying of the individual data
values (to a runtime formatting function). It's the difference
between compilation and interpretation.
> > This may be one of those situations where the runtime's
> > assistance is neither helpful nor necessary.
>
> It may also be that a few tweaks of the current code can speed up
> everything and satisfy the requirement for a generic binary interface.
A glance at the runtime/transport code suggests that while there are
opportunities for improvement (e.g. copying between various buffers in
io.c vs transport/*), these benefits would be shared by both printf
and the hypothetical binary trace widget.
> I prefer not to create some special case until we understand the
> whole problem.
What understanding do you think we lack?
- FChE