My app uses CoreML to run neural network (CoreML use CPU for most layers). Some time my performance is very good but after 30 seconds speed become slowly (fps is much less). I profiled it and found, that iOS use performance core for my app at the beginning. After 30 seconds it stops use Performance cores and starts use efficient cores (them frequency is less). You may see to on the screenshot. qos of my queue is .userInitiated. Also I tried .userInteractive, but is don't change anything. I assume that it is cores planning feature of iOS. But I cannot find any information about it. Is there documentation, which describe this behavior? Can I say iOS use performance core for my app all the time? I use iPhone XR with iOS 14.7.1.

Hello, I'm attempting to automate some performance tests we currently do manually using signposts and Instruments. It looks like XCTOSSignpostMetric is the perfect tool for the job, but I can't get it to play nicely. If I use the pre-defined signpost metric constants (customNavigationTransitionMetric, scrollDecelerationMetric, etc), it works fine. If I use a custom signpost using the XCTOSSignpostMetric.init(subsystem: category: name:) initializer, nothing happens. The documentation is very sparse on this topic and Googling, Binging, Githubing and Twittering have come up empty. I reduced the issue to the smallest example I could ( https://github.com/tspike/SignpostTest ). What am I doing wrong? Thanks, Tres Environment details: macOS 11.6 Xcode 12.5.1 iOS 14.6 iPhone SE 1st Gen In the app: ... let signpostLog = OSLog(subsystem: "com.tspike.signpost", category: "signpost") let signpostName: StaticString = "SignpostTest" @main struct SignpostTestApp: App { init() { os_signpost(.begin, log: signpostLog, name: signpostName) DispatchQueue.main.asyncAfter(deadline: .now() + .milliseconds(500), execute: { os_signpost(.end, log: signpostLog, name: signpostName) }) } ... } In the test    func testSignposts() throws {     let app = XCUIApplication() // No performance data let metric = XCTOSSignpostMetric.init(subsystem: "com.tspike.signpost",  category: "signpost",  name: "SignpostTest") // Works as expected // let metric = XCTOSSignpostMetric.applicationLaunch let options = XCTMeasureOptions() options.iterationCount = 1 measure(metrics: [metric], options: options, block: { app.launch() }) }

So, I need to know if the 16gb is enough for xcode development. Or I have to choose the 32gb? What I execute/open when I develop: xcode vsc ios simulator android emulator a few window of terminal one chrome window with so many tabs notes figma Thanks.

Starting from Xcode 12.4 (I think), failing unit tests in framework targets take about 5 seconds to complete. Successful tests complete almost instantly (as expected). For example, the following test:     func testExampleFailure() {         XCTFail()     } Takes 4.356 seconds to execute on my 2019 MacBook Pro: Test Case '-[FrameworkTests.FrameworkTests testExampleFailure]' failed (4.356 seconds). This seems to only affect unit tests in Framework targets (unit tests for App targets are unaffected). I have also tested this in fresh Framework template projects across multiple Macs, so it appears to be an Xcode bug. I'd hoped Xcode 13 would fix this issue, but it persists for me on Monterey. Perhaps someone could suggest a workaround?

I'm using xcrun xctrace export --output results.xml --input test_trace.trace --xpath '//trace-toc[1]/run[1]/data[1]/table' to export data from a test run with instruments as part of my app's CI. With Xcode 12 this resulted in an xml file that I could parse relatively quickly, but now with Xcode 13 the export process itself is taking 90+ seconds and generating a 160mb xml file for a 10 second recording. I noticed the table that has increased is the time-sample schema. Just attempting to export this table with --xpath '//trace-toc[1]/run[1]/data[1]/table[4]' takes quite a while. The table has about 790 thousand rows. I'm using a custom instrument based off the time profiler, and still have about the same number of stack trace samples in my output. Did anything change in Xcode 13 that caused instruments to include many more time samples that aren't corresponding to a stack trace? Is it possible to disable this to have fewer time samples in my trace (while preserving the stack trace frequency) so the xml can be parsed quicker?

We have an iPhone app where we are extensively using NSPredicate for array filtering. With iOS 15.1 upgrade, we started seeing performance issues with our app. After troubleshooting, we found slowness with array filtering, which otherwise works pretty fast on iOS 15.0.2 and below versions. Has anyone else faced such issue? If so, any resolution available? We couldn't find anything in release notes for iOS 15.1, which could cause this issue.

It seems that SpriteKit doesn't batch the draw calls for textures in the same texture atlas. There are two different behaviors, based on how the SKTextureAtlas gets initialized: The draw calls are not batched when the texture atlas is initialized using SKTextureAtlas(named:) (loading the texture atlas from data stored in the app bundle). But the draw calls seem to be batched when the texture atlas is created dynamically using SKTextureAtlas(dictionary:). The following images show the two different behaviors and the SpriteAtlas inside the Assets Catalog. 1. Draw calls not batched: 2. Draw calls batched: The SpriteAtlas: I created a sample Xcode 13 project to show the different behavior: https://github.com/clns/spritekit-atlas-batching. I have tried this on the iOS 15 simulator on macOS Big Sur 11.6.1. The code to reproduce is very simple: import SpriteKit class GameScene: SKScene { override func didMove(to view: SKView) { let atlas = SKTextureAtlas(named: "Sprites") // let atlas = SKTextureAtlas(dictionary: ["costume": UIImage(named: "costume")!, "tank": UIImage(named: "tank")!]) let costume = SKSpriteNode(texture: atlas.textureNamed("costume")) costume.setScale(0.3) costume.position = CGPoint(x: 200, y: 650) let tank = SKSpriteNode(texture: atlas.textureNamed("tank")) tank.setScale(0.3) tank.position = CGPoint(x: 500, y: 650) addChild(costume) addChild(tank) } } Am I missing something?

I have an multiple render-backend application on MacOS,so I can compare the performance between Metal and OpenGL about OffscreenRender. I found that, when I do not use MSAA,metal perform better.But when I open MSAA，especially at Large-texture，such as 3840x1920, metal seems slower. Then I simplify the render-pass, no draw call, seems it's the clear of texture was the difference of Metal and OpenGL, I'm not sure. in OpenGL,I use glClearBufferfv; in Metal, I set colorAttachments.loadAction=MTLLoadActionClear(I tried enalbe or disable tripple-buffering); Then I close the clear-action both on OpenGL and Metal,render-pass time of openGL reduce about 3ms ,Metal reduce about 8ms, Is that mean Metal take more time to clear texture? How can I resolve with such problem? (because I need clear-action) @Apple Device: Mac-mini-2018 Xcode: Xcode13.0 Here is the metal instrument screen-shot(idle of GPU seems too long,about 50ms):

When running on iPhone13 Pro Max (iOS15.1) and tapping the screen with several fingers in succession, it may go to 30fps at the moment of the tap. self.displayLink = [CADisplayLink displayLinkWithTarget: self selector: @selector(repaintDisplayLink)]; [self.displayLink setPreferredFramesPerSecond:60]; // or // [self.displayLink setPreferredFrameRateRange:CAFrameRateRangeMake(60,60,60)]; [self.displayLink addToRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode]; Unity and cocos2d-x are written with almost the same code, but the same phenomenon occurs. It is not reproduced on iPhoneXS MAX(iOS15.1), iPhoneSE2, iPhone7, etc. Also, if you set it to 120fps and run it, and then tap it continuously, the 120fps will turn into 60fps in the same way.

Hello, I'm investigating a crash where keyWindow is nil when I don't expect it to be nil. I would like to understand when this can happen. Indeed,I could make a fix by guarding for nil values, but this would lead to an invalid state. Context We want to return quickly from application(didFinishLaunchingWithOptions:), so: We set a view controller as a splash screen rootViewController => we mark the window with makeKeyAndVisible(). We queue initializations asynchronously on the main queue. => Basically, while the app is initializing starting, we're displaying a splash screen view controller. When the app is done initializing, it needs to present the actual UI. A last asynchronous task on the main queue does this. We get keyWindow from UIApplication to set the new view controller with the actual UI. That's where we assume that it shouldn't be nil and force-unwrap it, but alas, in some instances it's nil. Misc This crash only happens when app built with Xcode 13.x, running on iOS 15. I cannot reproduce this bug, and it has fairly little occurrence. (100s over 100000 of sessions) I also attached a sample crash Questions Given that I made the window "key and visible" in step 1, what could cause the window to stop becoming "key". What would be the correct way to get the window to set the new root view controller ? I don't really want to guard against a nil value because then it means that I wouldn't be able to set my new rootViewController and the app would be stuck on the launch screen. 2021-12-01_18-16-29.7629_-0700-9b5855582b13262f154acae64dd3140ad49c84f3.crash Thanks a lot! Bruno

In the App we saw a 4 seconds loading time while launching the App. Sometimes this time up to 8 seconds but the average time is 4 seconds. What could be the reason? In the AppDelegate there isn't server calls. The breakpoint inside the AppDelegate function didFinishLaunchingWithOptions is taking 4 seconds to get in. I have some api calls but they are launched after the breakpoint in the AppDelegate. The Api calls responses are working faster. In Instruments I have some blocked time, is it normal? Is something wrong in the log?

I just got an app feature working where the user imports a video file, each frame is fed to a custom action classifier, and then only frames with a certain action classified are exported. However, I'm finding that testing a one hour 4K video at 60 FPS is taking an unreasonably long time - it's been processing for 7 hours now on a MacBook Pro with M1 Max running the Mac Catalyst app. Are there any techniques or general guidance that would help with improving performance? As much as possible I'd like to preserve the input video quality, especially frame rate. One hour length for the video is expected, as it's of a tennis session (could be anywhere from 10 minutes to a couple hours). I made the body pose action classifier with Create ML.

Below, the sampleBufferProcessor closure is where the Vision body pose detection occurs. /// Transfers the sample data from the AVAssetReaderOutput to the AVAssetWriterInput, /// processing via a CMSampleBufferProcessor. /// /// - Parameters: /// - readerOutput: The source sample data. /// - writerInput: The destination for the sample data. /// - queue: The DispatchQueue. /// - completionHandler: The completion handler to run when the transfer finishes. /// - Tag: transferSamplesAsynchronously private func transferSamplesAsynchronously(from readerOutput: AVAssetReaderOutput, to writerInput: AVAssetWriterInput, onQueue queue: DispatchQueue, sampleBufferProcessor: SampleBufferProcessor, completionHandler: @escaping () -> Void) { /* The writerInput continously invokes this closure until finished or cancelled. It throws an NSInternalInconsistencyException if called more than once for the same writer. */ writerInput.requestMediaDataWhenReady(on: queue) { var isDone = false /* While the writerInput accepts more data, process the sampleBuffer and then transfer the processed sample to the writerInput. */ while writerInput.isReadyForMoreMediaData { if self.isCancelled { isDone = true break } // Get the next sample from the asset reader output. guard let sampleBuffer = readerOutput.copyNextSampleBuffer() else { // The asset reader output has no more samples to vend. isDone = true break } // Process the sample, if requested. do { try sampleBufferProcessor?(sampleBuffer) } catch { /* The `readingAndWritingDidFinish()` function picks up this error. */ self.sampleTransferError = error isDone = true } // Append the sample to the asset writer input. guard writerInput.append(sampleBuffer) else { /* The writer could not append the sample buffer. The `readingAndWritingDidFinish()` function handles any error information from the asset writer. */ isDone = true break } } if isDone { /* Calling `markAsFinished()` on the asset writer input does the following: 1. Unblocks any other inputs needing more samples. 2. Cancels further invocations of this "request media data" callback block. */ writerInput.markAsFinished() /* Tell the caller the reader output and writer input finished transferring samples. */ completionHandler() } } } The processor closure runs body pose detection on every sample buffer so that later in the VNDetectHumanBodyPoseRequest completion handler, VNHumanBodyPoseObservation results are fed into a custom Core ML action classifier. private func videoProcessorForActivityClassification() -> SampleBufferProcessor { let videoProcessor: SampleBufferProcessor = { sampleBuffer in do { let requestHandler = VNImageRequestHandler(cmSampleBuffer: sampleBuffer) try requestHandler.perform([self.detectHumanBodyPoseRequest]) } catch { print("Unable to perform the request: \(error.localizedDescription).") } } return videoProcessor } How could I improve the performance of this pipeline? After testing with an hour long 4K video at 60 FPS, it took several hours to process running as a Mac Catalyst app on M1 Max.

In our AR app and appclip made with SceneKit, we experience very significant drops in framerate when we make our 3D content appear at different steps of the experience. For now all of our 3D objects are in our Main Scene. Those which are supposed to appear at some point in the experience have their opacity set to 0.01 at the beginning and then fade in with a SCNAction (the reason why we tried setting their opacity to 0.01 at start was to make sure that these objects are rendered from the start of the experience). However, if the objects all have their opacity set to 1 from the start of the experience, we do not experience any fps drop. It is worth noting that the fps drops only happen the first time the app is opened. If I close it and re-open it, then it unfolds without any freeze. What would be the best way to load (or pre-load) these 3D elements to avoid these freezes? We have conducted our tests on an iPhone X (iOS 15.2.1), on an iPhone 12 Pro (iOS 14), and on an iPad Pro 2020 (iPad OS 14.8.1).

Debugging gputrace from M1 Max on older hardware in XCode warns "No compatible devices connected" and to "Connect a device that supports the screen resolution and Metal feature profile that this gputrace file was generated on. Seriously? I was boasting about XCode/Metals ability to get a gputrace and play it back, which is super helpful, but this was quite a let down. Is there no way other than buying a new Mac with M1 Max to get a look at the gputrace?

For a Create ML activity classifier, I’m classifying “playing” tennis (the points or rallies) and a second class “not playing” to be the negative class. I’m not sure what to specify for the action duration parameter given how variable a tennis point or rally can be, but I went with 10 seconds since it seems like the average duration for both the “playing” and “not playing” labels. When choosing this parameter however, I’m wondering if it affects performance, both speed of video processing and accuracy. Would the Vision framework return more results with smaller action durations?

When I try to use instruments most of the time I can't identify the threads. I'm assuming these are "internal" threads? One of the threads was causing the CPU to go up to 100% usage. I didn't change anything in the code, how do I identify what is causing these issues.

How well does SolidWorks perform using Windows on a MacBook Pro with the M1 Max chip and 64GB unified memory? I’ll likely be running Windows through Parallels.

When there is a large number of supplementary views, scrolling is extremely slow. To reproduce: Download Apple's demo of "Implementing Modern Collection Views" from here Open project in Xcode and show PinnedSectionHeaderFooterViewController.swift Go to line 106 and replace it with let sections = Array(0..<3000) Run project, navigate to "Pinned Section Headers" page, and try scrolling. Scrolling is barely possible and extremely slow! While profiling with Time instrument, issue seems to rely in invalidating supplementary views. Screenshot attached below. How can I fix this? (I have many section headers in my view)

Scrolling a collection view with a large number of supplementary header views is extremely slow. The more sections, the worst is the scrolling performance. (Tested with 5,000 sections). Best to give it a try and see for yourself. Code is available at https://github.com/yoasha/CollectionViewTest To reproduce, run the demo app with Xcode on either iPhone or iPad simulator (or a real device), select "Collection View" on the main page, and try to scroll. Any thoughts?