Re:A taste of CoreData – A graph framework
by mpweiher on Tuesday February 20, 2018 @09:18AM
(#16420426)
Hmm...parent is actually correct. What you write is true with very slow databases, particularly when talking to enterprise databases over a network.
"Fortunately", CoreData is so slow that as long as you stay within that universe, your view will never be invalidated.
Outside, however, computers are blazingly fast in general and I/O throughput is also incredibly fast. My laptop can read/write 2 GB/s. That's a lot. Moby Dick is around 1.25 MB. This means that you can write this whale of a book, in its entirety, 800 times per second. That's a lot. But I repeat myself...because it's worth repeating.
CoreData helps you optimize/minimize the size of transactions. Except for a very few cases, that's the wrong thing to optimize, as all our storage has amazing throughput and not-so good per-transaction and seek costs. Getting 1 byte from disk is almost as expensive as getting 1 megabyte, and having a bunch of smaller transactions is almost always a loss compared to one large transaction.
"Fortunately", CoreData is so slow that as long as you stay within that universe, your view will never be invalidated.
Outside, however, computers are blazingly fast in general and I/O throughput is also incredibly fast. My laptop can read/write 2 GB/s. That's a lot. Moby Dick is around 1.25 MB. This means that you can write this whale of a book, in its entirety, 800 times per second. That's a lot. But I repeat myself...because it's worth repeating.
CoreData helps you optimize/minimize the size of transactions. Except for a very few cases, that's the wrong thing to optimize, as all our storage has amazing throughput and not-so good per-transaction and seek costs. Getting 1 byte from disk is almost as expensive as getting 1 megabyte, and having a bunch of smaller transactions is almost always a loss compared to one large transaction.