DTrace support

[wereHamster]

Solaris, MacOSX and FreeBSD now have DTrace. It's a nice framework for instrumenting applications. Apart from tracing function calls (entry and return), applications can manually define probes. Such could be used to instrument how Transmission interacts with peers (choke, unchoke, send/request piece etc) and so improve the algorithm.

[wereHamster]

DTrace support

[charles]

This is going to sound like an ignorant question, but what do I do with that patch? Two of the files in it say that they're in /dev/null.

[wereHamster]

Replying to charles:

This is going to sound like an ignorant question, but what do I do with that patch? Two of the files in it say that they're in /dev/null.

The patch should be fine, just apply it. It's trac that doesn't handle git-generated patches.

It's only a very basic patch anyway, so that you see how dtrace works. You basically put TR_DTRACE() macros into your code, then compile dtrace.d with the dtrace utility and link the resulting .o file into the binary. That's it. Pretty simple, isn't it? :)

Regarding the Makefile, I don't know if apps_ldadd += dtrace.o is the correct way. Another way would be to add 'dtrace.d' to libtransmission_a_SOURCES and then tell 'make' how to compile .d files. But somehow I couldn't get that to work.

Also, you should say what kind of statistical data is important to you and add probes at the appropriate places. Currently there is just one probe that's fired when clients are unchoked (I believe that's what the code does, I'm not even 100% sure).

[charles]

wereHamster: this looks like it'll be useful for developers, but 99% of end users will never look at this. Shouldn't it be disabled by default?

[wereHamster]

Pretty much the whole Solaris kernel and many of the userspace tools that Sun ships have probes in them. Just adding dtrace support to the binary doesn't slow the application down. Only when you enable the probes there will be a small impact on the performance. You can easily enable many thousand probes in the kernel and users working on the same computer won't even notice that someone is profiling the system. That's the whole point of dtrace ;) So I'd say enable dtrace support if possible, it doesn't hurt.

[charles]

wereHamster: I appreciate the patch, but I really don't see the need for this, at least not in the official codebase. It's not clear to me that many (or even any) users will use this feature.