Brian King:
Xcode also supports Swift code generation, but I don’t think developers should use it. First off, the amount of code you have to write to use Core Data with Swift is less than with Objective-C, since there are not separate interface and implementation files and the property syntax is simpler. It’s not that hard to do by hand, as we’ll see. Second, types are so much more important in Swift, and NSManagedObject is actually incredibly smart when it comes to types and Swift.
[…]
By default, to-many relationships will be generated as
NSSet?. But who can deal with typeless containers these days? Use the native Swift
Set type instead.
[…]
If you’re using Core Data with Swift, I hope this inspires you to revisit you models and reduce the amount of force casting and optional unwrapping in your code.
In Xcode 7.3:
The NSManaged attribute can be used with methods as well as properties, for access to Core Data’s automatically generated Key-Value-Coding-compliant to-many accessors.
@NSManaged var employees: NSSet
@NSManaged func addEmployeesObject(employee: Employee)
@NSManaged func removeEmployeesObject(employee: Employee)
@NSManaged func addEmployees(employees: NSSet)
@NSManaged func removeEmployees(employees: NSSet)
These can be declared in your NSManagedObject subclass.
Core Data iOS iOS 9 Key-Value Coding (KVC) Mac Mac OS X 10.11 El Capitan mogenerator Programming Swift Programming Language
Mike Ash:
Still, the speed of objc_msgSend continues to astound me. Considering that it performs a full hash table lookup followed by an indirect jump to the result, the fact that it runs in 2.6 nanoseconds is amazing. That’s about 9 CPU cycles. In the 10.5 days it was a dozen or more, so we’ve seen a nice improvement. To turn this number upside down, if you did nothing but Objective-C message sends, you could do about 400 million of them per second on this computer.
[…]
It appears to have slowed down since 10.5, with an NSInvocation call taking about twice as much time in this test compared to the old one, even though this test is running on faster hardware.
A retain and release pair take about 23 nanoseconds together. Modifying an object’s reference count must be thread safe, so it requires an atomic operation which is relatively expensive when we’re down at the nanosecond level counting individual CPU cycles.
[…]
In the old test, creating and destroying an autorelease pool took well over 300ns. Here, it shows up at 25ns.
[…]
Objective-C object creation also got a nice speedup, from almost 300ns to about 100ns. Obviously, the typical app creates and destroys a lot of Objective-C objects, so this is really useful. On the flip side, consider that you can send an existing object about 40 messages in the same amount of time it takes to create and destroy a new object, so it’s still a significantly more expensive operation, especially considering that most objects will take more time to create and destroy than a simple NSObject instance does.
C++ Programming Language iOS Mac Memory Management Objective-C Optimization Programming
Jason Koebler (via Slashdot):
Here is the truth: Apple paid independent recyclers to recycle old electronics—which were almost never Apple products, by the way—because it’s required by law to do so. Far from banking $40 million on the prospect, Apple likely ended up taking an overall monetary loss. This is not because Apple is a bad actor or is hiding anything, it’s simply how the industry works.
[…]
In this sense, electronics recycling often works a lot like carbon offset credits, according to Kyle Wiens, CEO of iFixit, a company focused on helping people reuse and repair their electronics rather than recycle them.
“What they really do is cut recyclers a check and say ‘Can we have credit for a million of your pounds?” Wiens told me.
[…]
“The ironic thing is most of the gold is in old PCs and servers,” Wiens said. There’s very little gold in an iPhone.”
Apple Environment iPhone
John McCall (via Ole Begemann):
The standard library team asked the compiler team to take a look at the performance of the type-checker.
Their observation was that several in-progress additions to the standard library were causing a
disproportionate increase in the time it required to compile a simple-seeming expression, and they were
concerned that this was going to block library progress. This is the resulting analysis.
[…]
In general, it is expected that changes to the source code can cause non-linear increases in type-checking
time. For one, all type systems with some form of generic type propagation have the ability to create
exponentially-large types that will generally require exponential work to manipulate. But Swift also
introduces several forms of disjunctive constraint, most notably overload resolution, and solving
these can require combinatorial explosions in type-checker work.
[…]
Note that there have been proposals about restricting various kinds of implicit conversions. Those
proposals are not pertinent here; the implicit conversion are not a significant contributor to this
particular problem. The real problem is overloading.
Compiler Language Design Optimization Programming Swift Programming Language
