{"id":850,"date":"2022-01-04T19:38:48","date_gmt":"2022-01-04T17:38:48","guid":{"rendered":"https:\/\/www.juustila.com\/antti\/?p=850"},"modified":"2022-01-04T19:38:48","modified_gmt":"2022-01-04T17:38:48","slug":"swift-tree-structures-value-types-enums-and-classes","status":"publish","type":"post","link":"https:\/\/www.juustila.com\/antti\/2022\/01\/04\/swift-tree-structures-value-types-enums-and-classes\/","title":{"rendered":"Swift tree structures: value types, enums and classes"},"content":{"rendered":"\n

What if you need to define a tree like structure of data elements in Swift? For example you might use a Binary Search Tree<\/a> to keep track of unique words in a book file:<\/p>\n\n\n\n

\"A
An example of a binary search tree with unique word counts from a text file.<\/em><\/figcaption><\/figure><\/div>\n\n\n\n

Since value types are often preferred in Swift, you could use a struct. The Node struct contains the word, the count of it in the book, a key to manage the tree, and optional left and right child nodes of the tree.<\/p>\n\n\n\n

\"struct<\/figure>\n\n\n\n

But as you can see from the error message “Value type ‘Node’ cannot have a stored property that recursively contains it” — recursive<\/em> value types are not supported in Swift. A Node in the tree struct cannot contain the left and right child nodes when using value types. <\/p>\n\n\n\n

What to do? You have (at least) two options:<\/p>\n\n\n\n

  1. Use the enum<\/code> type with associated values.<\/li>
  2. Use classes.<\/li><\/ol>\n\n\n\n

    With Swift enums<\/a>, you can define two states for the enumeration. Either a) the node in the tree is Empty (there is no node) or b) it has associated values<\/em> in a Node — the word, the word count, key used to arrange the nodes in the tree by the word hash value, and the optional left and right subtrees:<\/p>\n\n\n\n

    \"indirect
    A tree node as an enumeration with associated values.<\/em><\/figcaption><\/figure>\n\n\n\n

    When defining recursive enumerations, you must use the indirect<\/code> keyword to indicate recursion in the enumeration.<\/p>\n\n\n\n

    The other option is to use classes<\/strong>, which are reference type elements in Swift:<\/p>\n\n\n\n

    \"final<\/figure>\n\n\n\n

    You can read more about Swift structs and classes from here<\/a> if you are unfamiliar with them.<\/p>\n\n\n\n

    Check out the full implementation of both class based and enum based solutions from this GitHub repository<\/a>.<\/p>\n\n\n\n

    So, are there any other differences in the enum and class implementations, than the differences in code? <\/p>\n\n\n\n

    Let’s check out. First run below is using the enum implementation, and the second one is executed using the class based implementation.<\/p>\n\n\n\n

    > swift build -c release\n> .build\/release\/bstree ..\/samples\/tiny.txt ..samples\/ignore-words.txt 100\n...\nCount of words: 44, count of unique words: 32\n>>>> Time 0.0008840560913085938 secs.\n\n\n> swift build -c release\n> .build\/release\/bstree ..\/samples\/tiny.txt ..samples\/ignore-words.txt 100\n...\nCount of words: 44, count of unique words: 32\n>>>> Time 0.0009189844131469727 secs.<\/code><\/pre>\n\n\n\n
    So far so good. Both implementations work (not all results not shown above) and seem to be quite fast. The tiny text file contains only 44 words of which 32 are unique.<\/p>\n\n\n\n
    But when executing both implementations with a larger 16MB file with 2674582 words of which 97152 are unique…:<\/p>\n\n\n\n
    > .build\/release\/bstree ..\/samples\/Bulk.txt ..samples\/ignore-words.txt 100\n...\nCount of words: 2674582, count of unique words: 97152\n >>>> Time 16.52852702140808 secs.\n\n\n> .build\/release\/bstree ..\/samples\/Bulk.txt ..samples\/ignore-words.txt 100\nCount of words: 2674582, count of unique words: 97152\n >>>> Time 3.5031620264053345 secs.<\/code><\/pre>\n\n\n\n
    You can see that the first enum based implementation took 16.5 secs to process the same file the class based implementation only took 3.5 secs to process. This is a significant difference. Why this happens?<\/p>\n\n\n\n
    Swift enums behave like value types. When the algorithm reads a word from the book file, it searches if it already exists in the tree. If yes, the old enum value is replaced with the new one in the tree. This results in copying the tree since it is now mutated. The Swift book<\/a> says:<\/p>\n\n\n\n
    “All structures and enumerations are value types in Swift. This means that any structure and enumeration instances you create\u2014and any value types they have as properties\u2014are always copied when they\u2019re passed around in your code.”<\/p>— Swift Language Guide<\/cite><\/blockquote>\n\n\n\n
    So whenever a node in the tree is modified, that results in copying the tree. When you change the tree by adding to it, the tree is copied. Using classes this does not happen. The excessive copying of the tree nodes is a performance killer when having very large data sets to handle. <\/p>\n\n\n\n
    There is also a performance penalty in using classes — each time a class instance is accessed, the retain \/<\/a> <\/a>release count is updated<\/a>. But as you can see, still the implementation is much faster compared to copying the structure with value types.<\/p>\n\n\n\n
    Summarizing<\/strong>, enums are a nice way to implement recursive data structures. If you have large data sets and\/or the tree or tree nodes are updated often, consider using classes instead.<\/p>\n","protected":false},"excerpt":{"rendered":"
    What if you need to define a tree like structure of data elements in Swift? For example you might use a Binary Search Tree to keep track of unique words in a book file: Since value types are often preferred in Swift, you could use a struct. The Node struct contains the word, the count … Continue reading “Swift tree structures: value types, enums and classes”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[2],"tags":[48,74,60,39,46],"class_list":["post-850","post","type-post","status-publish","format-standard","hentry","category-coding","tag-algorithms","tag-binary-search-tree","tag-data-structures","tag-performance","tag-swift"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.juustila.com\/antti\/wp-json\/wp\/v2\/posts\/850","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.juustila.com\/antti\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.juustila.com\/antti\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.juustila.com\/antti\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.juustila.com\/antti\/wp-json\/wp\/v2\/comments?post=850"}],"version-history":[{"count":1,"href":"https:\/\/www.juustila.com\/antti\/wp-json\/wp\/v2\/posts\/850\/revisions"}],"predecessor-version":[{"id":857,"href":"https:\/\/www.juustila.com\/antti\/wp-json\/wp\/v2\/posts\/850\/revisions\/857"}],"wp:attachment":[{"href":"https:\/\/www.juustila.com\/antti\/wp-json\/wp\/v2\/media?parent=850"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.juustila.com\/antti\/wp-json\/wp\/v2\/categories?post=850"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.juustila.com\/antti\/wp-json\/wp\/v2\/tags?post=850"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}