When switching between optimised (-O2) and non-optimised (-Od) builds, the -O is usually all that Casey will change.
In %CommonCompilerFlags% we also specify -MTd, which tells the compiler to produce a debug multithreaded executable. However, in the linker flags for the game DLL, we specify -LD (not LDd, which is the debug equivalent). The compilation of the game DLL actually has both -MTd and -LD but I assume LD overrides it, as we get a .dll as output.
1) Is the -O flag the only thing which will make a significant difference in performance? Does a debug build built with -O2 run comparably to a non-debug build at -O2?
2) Are we deliberately making a debug version of the .exe and a non-debug version of the .dll for a particular reason?
In %CommonCompilerFlags% we also specify -MTd, which tells the compiler to produce a debug multithreaded executable. However, in the linker flags for the game DLL, we specify -LD (not LDd, which is the debug equivalent). The compilation of the game DLL actually has both -MTd and -LD but I assume LD overrides it, as we get a .dll as output.
1) Is the -O flag the only thing which will make a significant difference in performance? Does a debug build built with -O2 run comparably to a non-debug build at -O2?
2) Are we deliberately making a debug version of the .exe and a non-debug version of the .dll for a particular reason?
1) Yes. Debug information does not cost anything in performance. You can have debug info with -O2 and it will run with exactly same performance as debug build without -O2.
2) Not sure which day are you looking at, but for latest source code as of now both exe and dll are built with exactly same O2/Od/Zi flags.
2) Not sure which day are you looking at, but for latest source code as of now both exe and dll are built with exactly same O2/Od/Zi flags.
Firstly, thanks for the insanely fast response.
Just checked the latest on github. Yes, the -O setting is the same for both .exe and .dll, but there's also -LD specified on the .dll compilation specifically.
Regarding the other debug-related flags, it looks like we're using -Z7 rather than -Zi (although this doesn't seem significant), and also -Zo (which I don't even see listed in https://docs.microsoft.com/en-gb/...ler-options-listed-alphabetically)
Anyway, thanks to your answer I know that even if there's debug info in the .exe and/or .dll, it's purely an issue of file size, not performance.
mmozeiko
Not sure which day are you looking at, but for latest source code as of now both exe and dll are built with exactly same O2/Od/Zi flags.
Just checked the latest on github. Yes, the -O setting is the same for both .exe and .dll, but there's also -LD specified on the .dll compilation specifically.
Regarding the other debug-related flags, it looks like we're using -Z7 rather than -Zi (although this doesn't seem significant), and also -Zo (which I don't even see listed in https://docs.microsoft.com/en-gb/...ler-options-listed-alphabetically)
Anyway, thanks to your answer I know that even if there's debug info in the .exe and/or .dll, it's purely an issue of file size, not performance.
Edited by Twicetimes
on
LD is just a shortcut for cl.exe to make it pass /DLL to link.exe and to use /MT for cl.exe (which is default). You can skip using LD and then simply make sure you pass /DLL to link.exe.
/Zo is relatively new cl.exe argument that officially was introduced only in VS2015: https://msdn.microsoft.com/en-us/library/dn785163.aspx
But it was working also in VS2013. Just undocumented. In previous VS version (<2013) it was called /d2Zi+
/Zo is relatively new cl.exe argument that officially was introduced only in VS2015: https://msdn.microsoft.com/en-us/library/dn785163.aspx
But it was working also in VS2013. Just undocumented. In previous VS version (<2013) it was called /d2Zi+
Edited by Mārtiņš Možeiko
on
Good to know, thanks.