[Issue 13726] Build Phobos and Druntime with stack frames enabled (-gs)

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13726

--- Comment #3 from Vladimir Panteleev <thecybershadow at gmail.com> ---
(In reply to Walter Bright from comment #2)
> Every bit of performance matters. D is constantly being compared for speed
> with other tools.

One of the (if not the) most common criticism(s) for D has always been the
maturity of its tool chain. You can't concentrate on bare performance while
jeopardizing everything else.

This issue and pull requests are a follow-up to a #d IRC user whose program was
crashing due to the above-mentioned invalid memory operations. I assisted them
and tried to get them to run the program in a debugger and breakpoint
onInvalidMemoryOperationError, which didn't help. I suggested that he used
Digger to build a version of D with stack frames enabled, and even though this
was simpler than setting up the source code, patching makefiles and invoking
DMC make, IIRC at that point the user just gave up on D and left the channel.

> Building phobos for maximum debugging support is completely at odds with
> performance.

As I said, stack frames have a minimum impact on performance. They are a very
common instruction sequence, so I suspect modern CPUs recognize and optimize
their execution. I believe the release versions of the Microsoft C/C++ runtime
are also built with stack frames enabled.

Here are the times for running the Phobos unittests (best of 10):

30.180 seconds - Currently (no -gs)
30.211 seconds - With -gs added

The difference (31ms) is 0.1%, and at this scale and sample size, it might very
well be noise.

That said, I think it would be OK to remove stack frames from the release
version of Phobos once we start shipping a debug version which works
automatically with -debug via -debuglib.

BTW, speaking of performance, Phobos is currently built without -inline.
However, enabling it does not produce any visible effect when running the
benchmarks.

--