Solved Does building with DTrace probes make software "faster"?

[poorandunlucky]

I can't remember who said it, or where I read it, but I have a vague memory of someone saying building your ports with DTrace probes yielded software that was "faster"...

I don't really understand how, or why, but I have to admit it's usually selected by default, so I guess it could...

Does it?

I usually deselect "Build with DTrace Probes", but maybe it does, in fact, make software faster... I think once I forgot and I went "Hmm, this feels faster..." but it could be my imagination...

 

[SirDice]

It doesn't. DTrace is mainly used for debugging. As such adding code to allow for this debugging may actually make it slower, not faster.

DTrace is also used to find bottlenecks in code. If you know where the bottleneck is you can try and solve that specific issue. That would make things faster. But that's not because of DTrace, it's because someone used DTrace to find where the problems are.

 

[poorandunlucky]

It doesn't. DTrace is mainly used for debugging. As such adding code to allow for this debugging may actually make it slower, not faster.

DTrace is also used to find bottlenecks in code. If you know where the bottleneck is you can try and solve that specific issue. That would make things faster. But that's not because of DTrace, it's because someone used DTrace to find where the problems are.

That's what I thought, but I wanted to make sure...

Howcome DTrace is always a default options/selected in port build options?

 

[ralphbsz]

In addition to what SirDice says: DTrace also makes the executable code larger (as does not stripping debug symbols out), which makes the CPU cache less efficient (and caches are VERY important, since CPUs today are memory constrained), and uses more memory bandwidth, so it makes the code slower.

Howcome DTrace is always a default options/selected in port build options?

Because some intelligent person made a tradeoff, between software that can be debugged, and software that runs at the ultimate speed.

This is particularly sensible in today's world, where CPU cycles are so plentiful that they are fundamentally free. That's why today we run code written in Java and Python in production, instead of hand-optimized assembly. Today's constrained resource is software engineer time, and software quality, not CPU cycles (for most environments, excluding crazy corners like supercomputing and image processing).