<font size=2 face="sans-serif">Hello all,</font>
<br>
<br><font size=2 face="sans-serif">Let me start with my bottom line conclusions,
and then explain them:</font>
<br>
<br><font size=2 face="sans-serif">LTTng's size overhead and start-up time
overhead is huge! An application cannot use (directly or through linking
in shared libraries with TPs) more than about 1000-2000 tracepoints.</font>
<br>
<br><font size=2 face="sans-serif">I am working on incorporating LTTng
as an alternative logging method for an existing project, which already
has many thousands of places in the code that do logging of some data.</font>
<br>
<br><font size=2 face="sans-serif">By many thousands, I mean > 15K.</font>
<br>
<br><font size=2 face="sans-serif">I have basically written an automated
instrumentor that generates custom tracepoints, for every log location
plus 1 entry-tracepoints and 1 exit-tracepoint for every function.</font>
<br>
<br><font size=2 face="sans-serif">This totals about 100K tracepoints,
with approximately 600K different fields, and has increased the size of
the project's resulting executables from ~100MB to ~900MB (!!) - although
this is with debug symbols.</font>
<br>
<br><font size=2 face="sans-serif">Analysis of the reasons for this has
revealed some interesting (but discouraging) facts:</font>
<ol>
<li value=1><font size=2 face="sans-serif">Each tracepoint name is stored
in a static buffer sized 256 bytes, regardless of how long the name actually
is (contributing some 25MB to the size)</font>
<li value=2><font size=2 face="sans-serif">Each trace event field name
is store also in a 256-byte buffer (contirbuting another 150MB)</font>
<li value=3><font size=2 face="sans-serif">Each event / tracepoint holds
an event structure which holds the fields, etc. and is padded generously.</font></ol>
<br><font size=2 face="sans-serif">Additionally, there is a ton of code
to calculate the event size, its alignment, and to verify that the names
are not longer than the 256 byte buffer, and more.</font>
<br>
<br><font size=2 face="sans-serif">Some of this is either used just once,
or even never used, merely compiled to let the compiler complain if the
sizes are wrong, etc.</font>
<br>
<br><font size=2 face="sans-serif">Now this code won't be included if you
compile a statically linked executable, but my project compiles almost
everything into shared libs.</font>
<br>
<br><font size=2 face="sans-serif">Another big big problem is the time
it takes to register all of these tracepoints. For one of my executables
which includes ~10K tracepoints, it took over 5 seconds just to get to
"main()" due to tracepoint constructor code registering the tracepoints...</font>
<br>
<br><font size=2 face="sans-serif">I've started working on an alternative
method of doing the same...<br>
</font>
<br><font size=2 face="sans-serif">Is anyone already aware of this? Is
anyone already working on improving this? I'd be very happy to work together
on this.</font>
<br>
<br>
<br><font size=2 color=#000080 face="sans-serif">Amit Margalit</font>
<br><font size=2 color=#808000 face="sans-serif">IBM XIV </font><font size=2 face="sans-serif">-
<i>Storage Reinvented</i></font>
<br><font size=2 face="sans-serif">XIV-NAS Development Team</font>
<br><font size=2 face="sans-serif">Tel. 03</font><font size=2 face="Arial">-689-7774</font>
<br><font size=2 face="Arial">Fax. 03-689-7230</font>