Skip to content

Comment on Extending ltrace to make your Ruby/Python/Perl/PHP apps fasterparent

Comments

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.

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

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.

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.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.