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

--- Comment #1 from Vladimir Panteleev <thecybershadow@gmail.com> ---
https://github.com/D-Programming-Language/druntime/pull/1020 https://github.com/D-Programming-Language/phobos/pull/2697

--

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

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com

--- Comment #2 from Walter Bright <bugzilla@digitalmars.com> ---
Every bit of performance matters. D is constantly being compared for speed with other tools.

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

--

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

--- Comment #3 from Vladimir Panteleev <thecybershadow@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.

--

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

Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |code@dawg.eu
         Resolution|---                         |WONTFIX

--- Comment #4 from Martin Nowak <code@dawg.eu> ---
(In reply to Walter Bright from comment #2)
> Every bit of performance matters. D is constantly being compared for speed with other tools.
> 
> Building phobos for maximum debugging support is completely at odds with performance.

I agree with Walter here.
Instead we should link a debug version of phobos when building with -debug.

--

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

--- Comment #5 from Martin Nowak <code@dawg.eu> ---
It's also possible to improve the exception unwinding to use additional info [1] for functions without a stack frame.

[1]: http://wiki.dwarfstd.org/index.php?title=Exception_Handling

--

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

--- Comment #6 from Vladimir Panteleev <thecybershadow@gmail.com> ---
Martin, do you have a benchmark for which the performance difference is non-negligible?

I've been building D from source code on my server for a while now, just to enable stack frames. They are invaluable for debugging, I use them for production all the time. I am confident that at the moment, D will benefit more from stack frames in Phobos/Druntime than 0.1% in performance.

--

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

--- Comment #7 from Vladimir Panteleev <thecybershadow@gmail.com> ---
(In reply to Vladimir Panteleev from comment #3)
> 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.

Thinking about this more, I think this isn't the right approach. A debug build of Phobos/Druntime (with optimizations/inlining disabled and/or assertions enabled) would definitely have a huge performance impact. We just need stack frames, so that the user/debugger can read any stack traces that go through Phobos.

(In reply to Martin Nowak from comment #5)
> It's also possible to improve the exception unwinding to use additional info [1] for functions without a stack frame.
> 
> [1]: http://wiki.dwarfstd.org/index.php?title=Exception_Handling

I don't see how this is relevant. This is not about exception unwinding, but seeing a stack trace in debugger or Druntime output so you know why your program crashed.

--

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

--- Comment #8 from Martin Nowak <code@dawg.eu> ---
(In reply to Vladimir Panteleev from comment #7)
> > [1]: http://wiki.dwarfstd.org/index.php?title=Exception_Handling
> 
> I don't see how this is relevant. This is not about exception unwinding

Yes it is, C++ exception unwinding uses DWARF format for most ELF
architectures.
The encode in great detail how to unwind from the stack, which is a requirement
for nearly-zero-overhead exceptions. For example you don't have to move all
registers to the stack like dmd does currently.

--

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

--- Comment #9 from Vladimir Panteleev <thecybershadow@gmail.com> ---
I don't understand... I'm not sure what the scheme is on POSIX, but on Win32, exception frames and stack frames are completely separate (they form two distinct linked lists which do not overlap).

Last I checked, gdb was not satisfied with just -g, you still need to rebuild Phobos/Druntime with -gs to get proper stack traces. I still don't understand what this has to do with exception handling.

In either case, that only affects POSIX. The problem remains on Windows (despite PDB files supposedly having enough information for proper stack traces without stack frames).

--

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

--- Comment #10 from Sobirari Muhomori <dfj1esp02@sneakemail.com> ---
(In reply to Martin Nowak from comment #8)
> The encode in great detail how to unwind from the stack, which is a requirement for nearly-zero-overhead exceptions. For example you don't have to move all registers to the stack like dmd does currently.

AFAIK, DWARF works on function level, but ability to find stack without frame pointer requires working on instruction level. It's also completely ignorant about hardware exceptions, which happen on instruction level too.

--