__debug function performance

[TurkeyMan]

Are there any opportunities to optimise or improve the performance of these __debug functions?
They are extremely slow. I have a custom string type and if a struct contains a few strings, stepping feels really sluggish, and if there's an array anywhere in view; it takes seconds to 10s of seconds each step.

Why are they so slow? It doesn't seem right that setting up the call should be that much trouble? If I can understand the performance characteristics, maybe I can make improvements on the app side...?

I have NOT enabled the "switch GC" option, since I am confident all my __debug functions are @nogc.

[rainers]

I shortly looked at the CPU diagnostics of displaying 100 of your Strings and the debugger mostly waits for the call to be performed in the other process. AFAICT this needs multiple inter-process-communication (devenv.exe <-> msvcmon.exe <-> debuggee.exe) so I suspect there is some inefficient waiting going on.
Maybe that can optimized for arrays of objects with __debug methods, but that will get messy e.g. if it is only one field of the array element that has an __debugOverview method.

[TurkeyMan]

Hmmm, well, in its current state it's almost unusable. I think I'm going to have to turn the __debug feature off, because it's just too slow :/
Sadly, I don't think it's really reasonable to work without it either; not being able to inspect strings and arrays severely undermines the usefulness of a debug session.

If it's about ipc waiting, then finding any opportunities for batching up requests seems like the way to go... is the code structured in such a way that you can gather the requests rather than resolving them immediately, and then send them all to the debuggee in one batch? That might require a lib compiled into the debuggee offering a function which can receive a bundle of requests from the debugger, and then the debuggee might iterate the bundle and resolve them all in one big go? :/
So, rather than calling each __debug function independently, call one global __debug function from a lib, which would locally iterate the bundle of requests calling each __debug function on each object in the bundle?
If the lib is not linked, fall back on existing semantics. Should be simple to check if a global __debugResolveBundle symbol is present in the binary.
Might help the GC swapping too; just do it once around the bundle...

[TurkeyMan]

Maybe we could put a function in druntime that's present when building with symbols... at very least, I wouldn't be upset to link a lib.