offloading

I've seen some discussion around performance on the forums but nothing official. What is the best practice for [handleNewFlow:] , [handleOutboundDataFromFlow:], and [handleInboundDataFromFlow:] callbacks in a content filter? Are all flows funneled through a single serial queue that calls into my subclass? If so this seems like we are back in the days of early OS X with the kernel network funnel serializing all network traffic. Should I offload flow processing onto a concurrent queue and then pause the flow and return from my callback? Or just do all processing in the callbacks? And once I return an allow/deny verdict for the flow (without asking for more data) do I no longer see that flow's traffic in my content filter? That's what I would expect and it seems to be the case in actual practice too. For reference I never need to interact with the user. All of the rules are loaded from an EDR platform. I bring this up because we have users complaining of stuttering during Google Meet / Zoom, etc when ou

File system changes introduced in iOS 17 As part of iOS 17, tvOS 17, and watchOS 10, the system has reorganized where applications and their data containers are stored. In previous systems, both lived within the same volume but, starting in iOS 17, they will be stored on different volumes. What does this mean for you? Copying large amounts of data from the app bundle to a data container will take longer than in previous versions of iOS. Previously that copy would have occurred as an APFS file clone, but now the operation will occur as a standard copy, which may take much significantly longer. Because the data will need to be fully duplicated, storage usage will increase more than was the case in previous versions. You should minimize the data they copy out of their app bundle and avoid any unnecessary duplication of data between the app bundle and data container. When upgrading from previous system version, splitting the data into separate volumes may mean that there is insufficient space for all existing app

Hi there, I am working on a 3d game engine in Swift and Metal. Currently I dynamically generate vertex buffers for terrain chunks on the CPU and pass all models to the GPU via argument buffer and make indirect draw calls. Calculating where vertices should be is costly and I would like to offload the work to a compute shader. Setting up the shader was straightforward and I can see that it (at least as an empty function) is being executed in the CommandBuffer. However, I come to this problem: since I do not know ahead of time how many vertices a chunk of terrain will have, I cannot create a correctly-sized MTLBuffer to pass into the compute function to be populated for later use in a draw call. The only solution I could think of is something like the following: For each chunk model, allocate a VertexBuffer and IndexBuffer that will accommodate the maximum possible number of vertices for a chunk. Pass in the empty too-large buffers to the compute function Populate the too-large buffers and set the actua

I have been experimenting with different rendering approaches in Metal and am hitting a wall when it comes to reconciling bindless or GPU-driven approaches* with a dynamic scene where meshes can be added, removed, and changed. All the examples I have found of such approaches use fixed scenes, where all the data is fixed before the first draw call into something like a MeshBuffer that holds all scene geometry in the form of Mesh objects (for instance). While I can assume that recreating a MeshBuffer from scratch each frame would be possible but completely undesirable, and that there may be some clever tricks with pointers to update a MeshBuffer as needed, I would like to know if there is an established or optimal solution to this problem, or if these approaches are simply incompatible with dynamic geometry. Any example projects that do what I am asking that I may have missed would be appreciated, too. * I know these are not the same, but seem to share some common characteristics, namely providing your entire g

What is the time frame for an app to be offloaded if the user does not open it? Also, is there any way for an app be exempt from offloading? Moreover, how can we track the number of offloads?

I need to develop Emergency communication app. This app is not used frequently but it need to start immediately when user need to make emergency communication. If this app is not used for a month, it uninstalled by Offload unused apps feature. Is there way to put a flag into app to prevent uninstall? If application's Info.plist has setting like Preventing offloading unused apps, it would be great to me.

I have offloaded and deleted so much and i the storage does not go down at all. It is at nine gig now and I have absolutely nothing on my iPad. I feel like this is very suspicious. Nothing works to clear it off and Apple‘s excuse is it will go away. It’s not going away it’s getting worse. I have one game that I play along with, Hulu, Facebook and messenger and most of the time I have the circular thing going on on my screen and can’t play the game or watch anything. the iPad is paid for, the service is paid for. Apple, What more do you want?

I'm here to request clarification on a question we have. One of the flagship features of our iOS app is our Safari extension. We are worried that some users might activate, and never return to the app itself. after 90 days of no use for an app, the system usually offloads the app. What we wanted to know is, does having an enabled Safari extension prevent the app getting offloaded? Thanks for any help

Platform: macOS 12.4, MacBook Pro 2.3GHz Quad-Core i5, 16GB RAM I'm trying to read an OSLog concurrently because it is big and I don't need any of the data in order. Because the return from .getEntries is a sequence, the most efficient approach seems to be to iterate through. Iteration through the sequence from start to finish can take a long time so I thought I can split it up into days and concurrently process each day. I'm using a task group to do this and it works as long as the number of tasks is less than 8. When it works, I do get the result faster but not a lot faster. I guess there is a lot of overhead but actually it seems to be that my log file is dominated by the processing on 1 of the days. Ideally I want more concurrent tasks to break up the day into smaller blocks. But as soon as I try to create 8 or more tasks, I get a lockup with the following error posted to the console. enable_updates_common timed out waiting for updates to reenable Here are my tests. First - a pure iterative approach. No t