I have a ruleset that parses Metastock formula language. When I try to debug it, every "next statement" or "continue" process takes too much time like 20 30 sec. Is there any setting or configuration that can increase debugging performance without upgrading my processor ?
My VS 2022 version : Microsoft Visual Studio Enterprise 2022 (64-bit) - Current Version 17.4.4
My hardware : Intel(R) Core(TM) i7-10870H CPU @ 2.20GHz 2.21 GHz 32.0 GB (31.8 GB usable)
Thanks for replies. I didnt use BOOST_SPIRIT[_X3]_DEBUG. I just use IDE debug breakpoints. Without breakpoints it works normally. But when i place a breakpoint and try to debug it it is too slow. I guess it is because of huge callstack of boost::spirit calls
It's more likely that it's about the huge symbol names after name mangling (templates with deeply nested namespace qualifications). These names can end up being (multiple) kilobytes.
That's not a problem that can be solved except really by
(a) switching to a different compiler - one that presumably doesn't quite have the same performance bottle necks around debug symbol information. Mind you, this will only alleviate perceived speed issues. Don't imagine that the debug experience will somehow become "better"
(b) debugging the release version (!) (ReleaseWithDebug config). This will make a huge difference, since in the nature of Spirit expression templates the (vast) majority of template instantiations will be inlined, and as such evaporate from the debugged code (more importantly, the call stacks)
Like I said in my first comment:
By the way, "debugging boost spirit" is not something that I find useful. And you can see that I know how it works. Are you using
BOOST_SPIRIT[_X3]_DEBUGalready? – sehe yesterday
I'm pretty sure you're trying to solve an issue that is not best solved with a debugger. Perhaps we can help with your real question/problem instead? I have over a decade of Spirit (Qi, Lex, Karma and X3) experience waiting to help you with that.
The only real reason for me to ever debug into the code is to verify my assumption on a call-graph for specific template instantiations. This is both rare, and exclusively useful when trying to understand/verify assumptions about library implementation details. So, unless you're trying to understand implementation details, I think you're probably on the wrong track using the debugger.