{"id":36028,"date":"2011-08-29T20:33:29","date_gmt":"2011-08-29T20:33:29","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/andrewarnottms\/2011\/08\/29\/immutable-collections-with-mutable-performance\/"},"modified":"2021-10-04T09:16:41","modified_gmt":"2021-10-04T16:16:41","slug":"immutable-collections-with-mutable-performance","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/premier-developer\/immutable-collections-with-mutable-performance\/","title":{"rendered":"Immutable collections with mutable performance"},"content":{"rendered":"<p>In my <a href=\"https:\/\/devblogs.microsoft.com\/premier-developer\/read-only-frozen-and-immutable-collections\/\">last post<\/a>, I detailed the differences among read\/write, read only, frozen and immutable collection types.&nbsp; I described how immutable collections come with a hit to the garbage collector due to the garbage they generate during mutations.&nbsp; I have a very positive update on that topic.<\/p>\n<p>My previous implementation for the immutable collections used a truly immutable binary tree as its backing data structure.&nbsp; As a result, every individual mutation required a spine rewrite where (log n) nodes were recreated.&nbsp; For a batch of <em>m<\/em> changes, this meant <em>m log n<\/em> objects were created and immediately discarded.&nbsp; That&rsquo;s a <em>lot<\/em> of garbage.&nbsp; And all those memory allocations (and GC interruptions) hurt performance to the tune of about being twice as slow as mutable collections.<\/p>\n<p>By changing the collections to use a freezable binary tree data structure, spine rewrites retain new nodes that are mutable until the (bulk) operation has completed.&nbsp; As a result, only <em>log n<\/em> nodes are created instead of <em>m log n<\/em>.&nbsp; And those new nodes aren&rsquo;t garbage: they&rsquo;re the important &ldquo;new&rdquo; part of the updated collection.&nbsp; By eliminating all garbage from intermediate steps of mutations, I&rsquo;ve measured a 91% drop in overall memory allocation (the remaining 9% is not garbage) and a 50% improvement in performance.&nbsp; This brings performance and memory load of immutable collections on par with the mutable collections, while retaining all their immutable properties that make them so attractive.<\/p>\n<p>Is there anything worse about the immutable collections then?&nbsp; Yes, if you have rapid changes to the collections that you make individually (you don&rsquo;t batch them with AddRange or some similar method) then you still may produce a lot of garbage assuming you release each version as you update it, whereas a mutable collection may have vacant memory slots it can fill when you add elements, immutable collections do not, and thus allocate memory for every element addition.&nbsp; But as discussed in my previous post, this &ldquo;slack space&rdquo; is also a point against mutable collections as it wastes memory that isn&rsquo;t reclaimable until to release the entire collection.<\/p>\n<p>We expect (not promise) to ship these highly tuned immutable collections as a public CTP release soon.&nbsp; I&rsquo;m stoked.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In my last post, I detailed the differences among read\/write, read only, frozen and immutable collection types.&nbsp; I described how immutable collections come with a hit to the garbage collector due to the garbage they generate during mutations.&nbsp; I have a very positive update on that topic. My previous implementation for the immutable collections used [&hellip;]<\/p>\n","protected":false},"author":2685,"featured_media":37840,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[106,4617,3916],"class_list":["post-36028","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-permierdev","tag-net","tag-andarno","tag-immutability"],"acf":[],"blog_post_summary":"<p>In my last post, I detailed the differences among read\/write, read only, frozen and immutable collection types.&nbsp; I described how immutable collections come with a hit to the garbage collector due to the garbage they generate during mutations.&nbsp; I have a very positive update on that topic. My previous implementation for the immutable collections used [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/posts\/36028","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/users\/2685"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/comments?post=36028"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/posts\/36028\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/media\/37840"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/media?parent=36028"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/categories?post=36028"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/tags?post=36028"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}