Compile without -g option but I want to get more detailed debug info

-g does not change the code generated. It only adds debug information. Therefore it should not affect performance.

You should investigate why you are seeing a performance difference - that may reveal some useful information.

The optimisation settings are the ones that affect performance. If you need to have them on, then try the -Og optimisation setting. It will enable optimisations that do not interfere with debugging.

Finally, Production is generally not a great place to debug. Your other environments should be designed to reproduce all bugs that can occur on Production. The goal is to ensure that you never encounter a new bug on Production. Very difficult in practice of course, but consider spending less time on getting debug to work on Production and more time on getting your other environments to match so closely that you can identify (perhaps by comparing logs) and then reproduce the bug there. As a benefit, you'll catch more bugs before they reach Production.

You should compile with -g -O2, and (if you're sure it's necessary), strip the debug symbols to a separate symbols file. I can't remember the exact steps, as I usually let dh-strip do that for me when building packages, but the idea is that the symbols don't consume memory in the program's process - you load them into the debugger.

I wanna the best performance

What should I do?

Enable optimisation.

I wanna ... the most detailed debug info.

What should I do?

Disable optimisation (or if your compiler supports such option: enable only optimisation that doesn't interfere with debugging; -Og in case of g++) and enable debug symbols.

As you may notice, these requirements are in a conflict.

A decent compromise for debugging a dump from a release is to enable both optimisation, and enable debug info for the build, especially considering ...

I don't care the size of the program or any other file.

which is what the debug info mostly affect. There is no need to avoid enabling debug info unless you care about the size of the program.

You also want to set -fno-omit-frame-pointer so that you know where you are while debugging. It will slow down execution, as there is one less usable register, but debugging is a compromise between performance and information (and sometimes you need these to find out that the compiler assumed things in release mode!).

CMake uses by default -O3 for release and -O2 -g for release with debug info (useful for debugging and profiling), so you have a good start, just add the frame pointer to have a better context.

And yes, debugging in production? Scary. Find a reproducer.