User Profile

My application is a computationally intensive commercial application. I have a suite of tests that consist of 100 separate directories that have test scripts within them. The directories are independent and to speed up testing, I have multiple instances of my application running in parallel working on each directory launched from command line scripts in Terminal.app. This process of testing is much faster than if I launched a single instance of my application that tested each test directory in serial. This has worked great for the past several releases of macOS. About the only hiccup I had was when a change was introduced to macOS that caused my apps to sleep after a while but I was able to resolve that by using the caffeinate command. About a month ago, I finally upgraded my primary development 8-core i9 iMac to Big Sur. Before upgrading, running my tests on Catalina took about 2.5 hours. But after upgrading to Big Sur, the tests now took 3.5 hours. Well now after upgrading to Monterey, the tests now take almost 4 hours. What happened? Most of the differences in timings of the other directories was negligible though after the upgrade but I noticed that one of my test directories now takes 4 times as long as it used to. When I run that problematic directory with a single instance with no other instances running, its completion time is back to normal. I should also note that my application contains OpenMP support and each instance may use up to 4 cores (limited to 4 cores for testing purposes) depending on what is being tested. Is there an Info.plist key/value I need to add to allow my app maintain peak performance or perhaps something similar to the caffeinate command? This performance difference happens even when I use a version of my application that was built with Xcode 12.4 on an older Mac running Catalina so I don't think it's an SDK issue. One colleague suggested that perhaps Big Sur introduced an Intel processor security patch that slowed down processing power. But that doesn't explain why the timings for the majority of the test directories were unaffected.

After years of using the legacy build system, I finally gave in and decided to convert my project so that it would build using the modern build system. I gave in because rather than being warned that the legacy build system was deprecated, Xcode 13 now treats it like an error. My application is available for Windows and Linux too and uses common code written in C/C++ with the GUI written in objective-c (no Swift at all). There's also a console version and shared library version for Python support. There are multiple versions of my application (think lite, consumer, and pro) which I have as separate targets. The console and shared library versions are also separate targets. My application requires a bunch of support files that are contained outside of the main application in a separate directory so I have a custom build location Xcode project setting that places the application into that directory. The modern build system is very slow. I can do a fresh build of the third party libraries, frameworks, and multiple Universal versions of my app using the legacy build system in 8 minutes. The modern build system takes 16 minutes. After I do a fresh build, if I make no changes and build again, all my code (but not the third party libraries and frameworks for some reason) gets recompiled. After the second time though, selecting build again only recompiles changed files. This has been true for years though and is not unique to the modern build system. Although I used precompiled headers, it's not a PCH problem because I turned it off and still observed the same problem. Because I have separate versions of my application in addition to console and share library versions, I put the console and shared library in MyApp.app/Contents/MacOS/ directory. With the legacy build system, I could use set that as the build location for the console and shared library versions but the modern build system now complains about multiple commands producing the MacOS directory. So now I have to use an aggregate target (that has the different targets as dependencies) that copy the executable and library to the correct location. And now I have the original console executable and shared library lying around. Clean Build Folder no longer works due to the custom build location. I get error messages that the custom build directory can't be deleted. I now use make clean from a terminal with the -UseModernBuildSystem=NO option for xcodebuild in the makefile. I used to be able to use a single Info.plist file that's macro'd up that's shared by my multiple targets. I have a build phase script that reads the version and build number from a file and injects it into the Info.plist and reverts the file after a target has been successfully built (reverted for source control reasons). But Xcode wants to do parallelized builds so I can no longer modify/revert the single Info.plist file. Each target now must have their own Info.plist file even though they're all identical. Not a problem, I'll copy the source Info.plist file to the target Info.plist file as a build phase and inject the version number into that. Nope, the modern build system doesn't like having files not existing when it's preparing to build even though the files will eventually exist when it gets to that build step. The worse thing though is how slow the modern build system is.