Modding, Mission Design, and Coding > Test Builds

Possible Faster Debug

(1/6) > >>

Ages back I recall reading a tip on Bruce Dawson's blog about speeding up MSVC debug builds. I know this is currently a problem for modders as running FSO debug executables is very slow, making it hard to use debug execs for all modding. I know there's been a discussion about "fast debug" config which (IIRC) would involve optimised debugging, or essentially a MSVC release config with FSO debug, however the change Bruce suggested is super simple to make so I thought I'd give it a go as see what happened.

--- Quote ---In your project properties go to C/C++, Code Generation, and set Basic Runtime Checks to Default. Your code will get slightly smaller, and a lot faster.

--- End quote ---

So, here's a link to some DEBUG executables built with 2015 community edition; SSE2 mode.

It'd be great to have comparisons run between this and (e.g.) the nightly SSE2 builds (which might be compiled with a different version of MSVC... oh well). Note that my Windows laptop is pretty old & slow, so I don't think it'd give good test results.

Trivial diff here if anyone's interested:

I haven't tested this yet, but I was reading the blog entry you linked and saw this:

--- Quote ---the slowdown is triggered by a combination of Runtime Checks and Edit and Continue – disabling Edit and Continue can drastically improve debug performance.

--- End quote ---
You might also want to change the Debug Information Format to "Program Database (/Zi)" instead of "Program Database for Edit And Continue (/ZI)" (which it currently is for Debug builds)... unless it's talking about debug performance only while running the the program through VS's debugger, which isn't entirely clear to me.

Thanks for drawing my attention to that. It seems that it's the combo of the two that causes the slowdown. From the comments (emphasis mine)

--- Quote from: ---brucedawson says:   
June 3, 2015 at 9:00 am   

I’m sure they’ll fix it some day… Until then, turn off the checks, or turn of (sic) edit-and-continue.

--- End quote ---

From a quick read of MSDN it seems that this feature lets you edit your program and continue to debug it without recompiling. There's limitations though so this feature seems possibly less useful than setting Basic Runtime Checks to Default, which one commenter says causes issues in a certain game being compiled with /arch:SSE2.

Anyway, before I switch that around are there any coders that would be greatly upset at losing access to the "Edit & Continue" feature?

(ps, I've had one report via IRC that, while not hugely faster, there is some improvement with this change... although potentially mouse input events are being lost?)


--- Quote from: niffiwan on February 22, 2016, 02:45:54 am ---are there any coders that would be greatly upset at losing access to the "Edit & Continue" feature?

--- End quote ---
If there are, they can always compile an Edit & Continue build themselves, but given the severe limitations of the feature, I'm not sure how often it's likely to even be usable.

I've used Edit and Continue maybe like five times and I frankly won't miss it if it's disabled by default.


[0] Message Index

[#] Next page

Go to full version