{"id":32623,"date":"2006-01-18T10:00:16","date_gmt":"2006-01-18T10:00:16","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2006\/01\/18\/the-cost-of-trying-too-hard-splay-trees\/"},"modified":"2006-01-18T10:00:16","modified_gmt":"2006-01-18T10:00:16","slug":"the-cost-of-trying-too-hard-splay-trees","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20060118-16\/?p=32623","title":{"rendered":"The cost of trying too hard: Splay trees"},"content":{"rendered":"<p>Often, it doesn&#8217;t pay off to be too clever. Back in the 1980&#8217;s, I&#8217;m told the file system group was working out what in-memory data structures to use to represent the contents of a directory so that looking up a file by name was fast. One of the experiments they tried was the splay tree. Splay trees were developed in 1985 by Sleator and Tarjan as a form of self-rebalancing tree that provides <i>O<\/i>(log&nbsp;<i>n<\/i>) amortized cost for locating an item in the tree, where <i>n<\/i> is the number of items in the tree. (Amortized costing means roughly that the cost of <i>M<\/i> operations is <i>O<\/i>(<i>M<\/i>&nbsp;log&nbsp;<i>n<\/i>). The cost of an individual operation is <i>O<\/i>(log&nbsp;<i>n<\/i>) on average, but an individual operation can be very expensive as long as it&#8217;s made-up for by previous operations that came in &#8220;under budget&#8221;.)\n If you&#8217;re familiar with splay trees you may already see what&#8217;s about to happen.\n A very common operation in a directory is enumerating and opening every file in it, say, because you&#8217;re performing a content search through all the files in the directory or because you&#8217;re building a preview window. Unfortunately, when you sequentially access all the elements in a splay tree in order, this leaves the tree totally unbalanced. If you enumerate all the files in the directory and open each one, the result is a linear linked list sorted in reverse order. Locating the first file in the directory becomes an <i>O<\/i>(<i>n<\/i>) operation.\n From a purely algorithmic analysis point of view, the <i>O<\/i>(<i>n<\/i>) behavior of that file open operation is not a point of concern. After all, in order to get to this point, you had to perform <i>n<\/i> operations to begin with, so that very expensive operation was already &#8220;paid for&#8221; by the large number of earlier operations. However, in practice, people don&#8217;t like it when the cost of an operation varies so widely from use to use. If you arrive at a client&#8217;s office five minutes early for a month and then show up 90 minutes late one day, your explanation of &#8220;Well, I was early for so much, I&#8217;m actually still ahead of schedule according to amortized costing,&#8221; your client will probably not be very impressed.\n The moral of the story: Sometimes trying too hard doesn&#8217;t work.<\/p>\n<p> (Postscript: Yes, there have been recent research results that soften the worst-case single-operation whammy of splay trees, but these results weren&#8217;t available in the 1980&#8217;s. Also, remember that consistency in access time is important.) <\/p>\n","protected":false},"excerpt":{"rendered":"<p>Often, it doesn&#8217;t pay off to be too clever. Back in the 1980&#8217;s, I&#8217;m told the file system group was working out what in-memory data structures to use to represent the contents of a directory so that looking up a file by name was fast. One of the experiments they tried was the splay tree. [&hellip;]<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-32623","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"<p>Often, it doesn&#8217;t pay off to be too clever. Back in the 1980&#8217;s, I&#8217;m told the file system group was working out what in-memory data structures to use to represent the contents of a directory so that looking up a file by name was fast. One of the experiments they tried was the splay tree. [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/32623","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=32623"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/32623\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=32623"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=32623"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=32623"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}