macOS What is the performance loss of a Debug vs Release executable?

[Wowfunhappy]

I spent this past weekend making some personal customizations to an open-source Cocoa app.

When I was done, I realized there was a crash when I compiled a "Release" executable. The "Debug" executable worked fine, even when I enabled compiler optimizations. I was tired and I wanted to go to bed, so after an hour of fruitlessly attempting to find the cause of the crash, I called it a night and saved out a Debug executable with compiler optimizations enabled.

I would very much like to never think about this again, but it's nagging at me. Can anyone give me a very rough sense of how much performance I'm leaving on the table by using the Debug version?

 

[casperes1996]

Could be a different code path. Like if you have a #if debug / #ifdef DEBUG thing in there.

But if you have compiler optimisations turned on I don't think there should be any performance difference left, really. Only perhaps a larger executable if it contains debug symbols

 

[firewood]

Depends on what your app is doing, and how often it needs max performance.

One of my benchmarks apps (Chipmunk Basic running the Byte prime number benchmark) runs slightly over twice as slow from Debug builds compared to optimized Release builds.

 

[Senor Cuete]

In XCode you can set both the debug and build to build with optimizations. casperes1996 is probably correct that they are equally fast but if you figure it out it would be valuable to know if that is correct.

You don't say what language you are using or if you use XCode but I assume that you are because you mention optimizations. If it will build and run with optimizations on in the debug version it should do it in the release version as well. XCode is really good at reporting errors and warnings. You should treat warnings as errors. Also you don't say if your application is crashing after you archive it (this is when the release version would be compiled) and distribute it. It would be highly unusual if this is the case. The Code analyzer is really good at finding potential errors. I run it every time I am going to release a new version, either to distribute it myself or via the App store.

 

[Wowfunhappy]

Thank you so much everyone! I'm probably going to leave it and stop worrying about this!

Just to answer some questions:

You don't say what language you are using or if you use XCode but I assume that you are because you mention optimizations.

Ah, I guess I did leave that out! Yes I'm using XCode (but an old version, because I'm on 10.9), this app is Objective-C (because the 10.9-compatible version I'm working with mostly predates Swift).

Also you don't say if your application is crashing after you archive it (this is when the release version would be compiled) and distribute it. It would be highly unusual if this is the case.

Yes, the "archive" version crashes! I agree, it's weird. I think it might be some sort of memory alignment voodoo, since it's an "EXC_BAD_ACCESS" fault.

You should treat warnings as errors.

I should, yes... but see, the original developer clearly did not.

For whatever it's worth—because it wasn't my intention to be coy—the app I'm working with is OpenEmu. I love its Mac-native UI for playing games, I wasn't a fan of the whole organize-all-your-games shtick, because that's what good ol' Finder is for! (I also prefer QuickTime to iTunes.)

So, what I did last weekend was completely rip out the whole Library portion of the app, and adjust what was left of the UI to work like a standard document-based Cocoa app. The result is a mess of dead code, but the app itself (at least the debug version) is working exactly the way I want it.

 

[Senor Cuete]

I'm not familiar with the project but if you can build it as a single window project it's much simpler. In a Cocoa multiple window project you have to override a bunch of NSDocument functions and provide handlers for the application's data types, etc. In my multiple window application I had to implement these methods to get it to work:

- (void) setDocumentView: (NSView *) docView
- (void) windowDidResize: (NSNotification *) note //if you don't include this method the runtime will log a bunch of errors
-(void) userResizedWindow: (NSNotification *) note
- (void) windowDidMove: (NSNotification *) note
- (BOOL) windowShouldZoom:(NSWindow *)window toFrame:(NSRect)newFrame
- (void) canCloseDocumentWithDelegate: (id)delegate shouldCloseSelector: (SEL)shouldCloseSelector contextInfo: (void *)contextInfo
- (NSData *) dataOfType: (NSString *) typeName error: (NSError **) outError

I'm sure that your application is simpler than this one but developing a full-featured multiple-window application is much more complex.