[lttng-dev] Performance impact using the "filter" option
Ilya Mirsky
ilya.mirsky at gmail.com
Wed Mar 19 15:51:34 EDT 2014
Amit and Michel, I appreciate your replies.
Please see my comments below.
On Wed, Mar 19, 2014 at 5:09 PM, Michel Dagenais <michel.dagenais at polymtl.ca
> wrote:
> If I understand correctly, filtering is done at the client application
> side.
>
> With UST yes.
>
> This means that filtering could theoretically lower the performance of the
> running application which has to check, for each event, whether it should
> be sent to the daemon or not.
>
> Each event is checked against the filter and then written to the buffer or
> not. With a simple filter and most events filtered out, checking the filter
> is faster than writing to the buffer (with atomic operations to increment
> the buffer counters) and you definitely save (at each tracepoint and in the
> daemon with trace buffers filling more slowly). If the filter is
> complicated and most often keeps the event, then you certainly loose.
>
That's what I thought, but benchmarking showed that there's practically no
difference.
The filter is a simple ID comparison of the form 'id % 1,000 == 0', so 999
out of 1K tracepoints are filtered out.
Could you please point me to some references on this topic?
Thanks,
Ilya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20140319/1adf79bd/attachment.html>
More information about the lttng-dev
mailing list