iOS, Objective-C, Swift, Design and Whatever Comes in Mind

Memory Management of Value Types

Yesterday, I read a great article about value and reference types and how their performance behaves. I want to share my notes with you.



Stack Allocation

  • Fast and simple place to store data
  • Uses a stack pointer that points to the top of the stack
  • Each scope provides the amount of memory it needs to run before it gets executed, then the stack pointer is moved and the scope is executed. Now, the scope can add and remove data to the memory it got allocated.
  • When the scope is done, the stack pointer is decreased and its data deallocated
  • Very little costs as only an integer (the pointer) needs to be increased/decreased
  • Some forms of value types can be stored directly on the stack, as long as their sizes are known at compile time
  • They also must not be contained by a reference type or contain one, as it would require reference counting
  • Absence of reference counting overhead leads to an increased performance
  • When a value type is assigned, it gets copied (called Copy-On-Assignment). However, the copy is performed in a constant time.

Heap Allocations

  • Used for objects that are flexible in size and whose lifetime can be longer than the scopes
  • Pointers point to the object in memory
  • When a resource should be allocated, the memory management is asked to reserve a certain amount of memory for that resource
  • If the resource is not used anymore, its memory can be freed (managed for us by ARC)
  • Heap allocation is slower than stack allocation because the data structure is more complex (page tables, …) and it needs to be thread save (in comparison: every thread has its own stack)

Unfortunately, it is not as easy as ’value types go on the stack and reference typed to the heap’.

Value Types on the Heap

  • Every struct whose size is not known at compile time must be stored on the heap.
  • Heap allocation is necessary when the struct contains a reference type or is contained by one (or even recursively, meaning it stores a value type object that stores a reference type)
  • Common situation when for example storing @escaping closures or if the struct is stored by a class​ directly
  • Possible for the struct to perform worse than a class​ when it comes to copying
  • Value types, that store heap allocated class objects, will not be per-se stored on the heap but will gain a reference counting overhead
  • Stack allocated value types are copied in constant time, heap allocated value types are not and will take more time.
  • Copy-On-Write (COW) prevents it from being problematic and many Standard Libraries data structures make heavy use of it (e.g. Array, Dictionary and Set)
  • With COW, an assigned property will not be copied immediately but only if its content get mutated

Problems with Value Types that store Reference Types

  • Consider the following struct and class​ that contain many reference type objects:
  • The next snippet will create HugeClass and HugeStruct many times and check how long the creation takes
  • Result: the struct needs more time then class, because it uses copy-on-assignment, in comparison to the class which just increases a reference count
  • If executed not only 10_000_000 but 20_000_000 times, the struct needs more than twice the time than before, the time of class only merely increases
  • The more reference types a value type contains (more instances of EmptyClass in HugeStruct), the more reference counting overhead is added on copying it.

Takeaway

  • Improve the performance by replacing unnecessary references with proper static size value types
  • For example, this:
  • May be replaced by this:
  • Now, the struct is statically sized and the reference counting overhead is removed.
  • Also keep asking yourself if you really need a struct with its Copy-On-Write behavior or if a class would fit you better

"Memory Management of Value Types".

Swift 4 Change: Limit a Protocol Adaption to Reference-Type-Objects

Often I need to declare a protocol and need a weak reference to it. It is quite common in the delegation pattern.

In order to store a weak reference, the implementing type needs to be a reference type. Therefore, the protocol must limit the type of its implementation so that only classes can implement it.

Swift 4 now introduced a new, preferred way to declare a class-only protocol: ​AnyObject​.

However, the old way, where you have to use the ​class​ keyword still works fine. Prior to Swift 4, there were some subtle differences between these two keywords, which has been removed in SE-0156 - Class and Subytpe existentials.

So now you can declare a protocol like this:

Only objects can implement it, so the compiler will prevent the following code form beeing compiled:

In addition to that, the protocol can still be used by a weak reference, like

The old way, the ​class​ keyword is not yet deprecated, but you can start accustom yourself to using ​AnyObject​ now.

The information in this article are taken from here.

"Swift 4 Change: Limit a Protocol Adaption to Reference-Type-Objects".

WWDC18: Update to my Submission

As the day came, I was really looking forward to, I got this email:

Image of the email form apple

I got a scholarship and therefore I will go to WWDC 🎉!
It took my breath away and I needed a few moment to realize it. I will be one of approximately 300 students.

After my first astonishment calmed, I thought about all the things that I have to manage as soon as possible. For example, I never possessed a passport – I had no need for it. Now it is one of the most urgent things on my list, as the fabrication needs about four weeks.

I did a little research and made a phone call. As it turned out, there is a thing called ‚express passport order‘, which costs more than the regular one but will get me the urgently needed passport in about four days.
This weekend, I will place that order. When my passport arrives, I can start to go for a ESTA-visa.

In the meantime, I booked my flight to San Jose. It will departure from Frankfurt am Main and will bring me right to San Jose without any intermediate landing, which is great.

Lodging will be provided by Apple so fortunately I do not need to care about it, yet.


Oh, I am so exited about this opportunity!


If you want to follow me on my journey, follow me on twitter. I would also love to meet with as many cool persons as I can, so please also contact me 🙃

"WWDC18: Update to my Submission".