Why is it true that "weak is slower than strong"? Explain it with the Swift runtime's reference count layout: the inline refcount and the side table.
The inline refcount in the object header only holds the strong and unowned counts; the first weak reference allocates a side table and moves the counts there. From then on a weak variable points at the side table instead of the object, adding one level of indirection, and even strong operations on that object get slower.
Memory and ARCMultiple choiceIntro
Which of the following statements about weak references are correct? Select all that…
#weak
Memory and ARCShort answerBasics
A view controller doesn't seem to leave memory after you close its screen. How would you…
#weak
Memory and ARCShort answerBasics
When would you use unowned instead of weak?
#weak
Memory and ARCShort answerBasics
You try to declare weak var delegate: MyDelegate? and the compiler rejects it. Why, and…
#weak