

Extending ltrace to make your Ruby/Python/Perl/PHP apps faster - ice799
http://timetobleed.com/extending-ltrace-to-make-your-rubypythonperlphp-apps-faster/

======
sharms
This is very cool stuff. I usually debug my programs through log messages, but
this looks to be much easier / less performance impact.

~~~
jey
I don't know what you mean by less performance impact; ltrace works by putting
software breakpoints into the functions you want to trace, and such
breakpoints work by causing a soft interrupt (e.g. INT 3 on x86), which causes
a drop into kernel mode and invokes the appropriate interrupt handler, then
the kernel suspends the process that caused the interrupt and queues the
ltrace process which is ptrace-ing your app to be woken up when the scheduler
thinks it's convenient, then ltrace has to write out its output after it
figures out why it was woken up, yadda yadda, etc etc... overall it's pretty
heavy-weight in comparison to a log message, but in practice is probably only
a negligible performance impact for 99.9%+ of programs.

~~~
sharms
Right but I can selectively run ltrace, where as my logging statements are
always in the code, and if statements have to be evaluated etc

~~~
jfarmer
It's not about performance; it's about not having logging statements in the
code and/or having to add them when something goes awry.

~~~
thwarted
One shouldn't remove asserts() just because you're going to ship code, you
just #define assert() to expand nothing. Same applies to languages other than
C that don't have a pre-processor: you can define a null function, and
hopefully your runtime is awesome enough to optimize calls to it away.

------
jbert
What am I missing? all mysql calls have to go over a system call, so strace
will see them (as write() or send() I guess).

Why use ltrace for this job?

~~~
tmm1
Using strace to trace mysql traffic is painful. You have to know which file
descriptors to trace (check via lsof first), then trace all network traffic on
those fds in verbose mode to see the queries themselves (doesn't work if the
mysql protocol has compression enabled), and then try to figure out how long
each of the queries took to execute by matching queries and responses.

ltraceing mysql_send_query() gives you all this information in one line.

~~~
tmm1
Plus, you can trace a lot more than mysql queries.. commonly used libraries
like libMagick, libxml, libcurl, libmemcached, and even internal VM functions
like garbage_collect(), PyEval_SafeThread(), etc.

