@Benji is trying to load some CoreData concepts into his longterm memory banks:
... fetch data from the database on every single view.....Does that give me any benefits like performancewise?
Or would it even put more workload on the app?
These are concepts that database programmers have always battled. Access vs Performance. Fresh data vs Stale data.
Please note: I don't back up my observations with hard scientific proof.
But in my readings and education journey, I've settled on a comfort level that unless I'm working with tons of data, millions of records, the performance of chips in iPhones and iPads will never be challenged by CoreData lookups. Also, CoreData was written by boffins who baked in caches and fetch optimizations, leaving you to focus more on the business at hand.
Have you bought Donny Walls' book?
See -> Practical Core Data
It's your fault!
In Chapter 4, he discusses some of your points. Pay particular attention to faults
.
Chapter 4:
..... snip ...... In addition to learning more about retrieving data, you will also learn about faults, batch insert,
delete, and update requests, merge policies, and query generations. By the end of this chapter,
you should have a pretty solid understanding of how you can manipulate the data
10/10 Would recommend. 👍🏼
Apple's documentation:
Faulting reduces the amount of memory your application consumes. A fault is a placeholder object that represents a managed object that has not yet been fully realized or a collection object that represents a relationship...
CoreData is vigilent in keeping its object graph optimized when your application is in play. So while you may load a number of Dealer
objects from your persistent store, CoreData may only load a portion of that Dealer's Car
objects, or load placeholders. CoreData works hard to prevent you from loading objects, until you actually need them. (See documentation and Wal's book for more in-depth knowledge.)
See -> It's your fault!
Brief excerpt:
When a fault is fired, Core Data does not go back to the store if the data is available in its cache.
With a cache hit, converting a fault into a realized managed object is very fast—it is basically the same
as normal instantiation of a managed object. If the data is not available in the cache, Core Data
automatically executes a fetch for the fault object; ....snip.....
Xcode and Instruments
Finally, tell us how you're using Xcode's Instruments
application. Are you profiling your CoreData app?
Please share how Instruments
reveals interaction between your CoreData API calls, and the data residing on your device. This may be revealing!
Watch -> WWDC 22 Instruments and CoreData
Keep coding!
Please share your CoreData results with us!