{"id":68,"date":"2008-02-10T01:50:56","date_gmt":"2008-02-10T05:50:56","guid":{"rendered":"http:\/\/www.cchsu.com\/art-en\/2008\/02\/10\/68\/"},"modified":"2008-02-10T01:50:56","modified_gmt":"2008-02-10T05:50:56","slug":"things-learned-from-performance-tuning","status":"publish","type":"post","link":"https:\/\/www.cchsu.com\/art-en\/2008\/02\/10\/68\/","title":{"rendered":"Things Learned from Performance Tuning"},"content":{"rendered":"<p>One major blocker for a\u00a0software project to finish is unsatisfactory performance.\u00a0 Engineers always are asked to tune the performance to customers&#8217; satisfaction no matter what.\u00a0 Performance tuning itself is a very interesting topic and I&#8217;d like to share some interesting things that I&#8217;ve encountered before.<\/p>\n<p>Two main performance tuning targets are reducing execution time or shortening waiting time.\u00a0 Reducing execution time is typically related to back-end applications.\u00a0 I had involved in a banking software project which had a\u00a019.5-hour batch.\u00a0 Well, you know this is way too absurd to be acceptable.\u00a0 After continuous tuning for a month, the batch later took 19 minutes to complete.\u00a0 It might not be common to see such drastic results, however, I did learn something very interesting:<\/p>\n<ul>\n<li>The table design of a database is very important.\u00a0 Most of the\u00a0(banking) projects that I&#8217;ve involved before design their database based on existing table structures from the customers.\u00a0 Unfortunately, theses table structures are not likely well optimized (at least for the project you are working on).\u00a0 In the very beginning of the project, we need to identify the most frequent or critical query path, and design the table structures accordingly.<\/li>\n<li>The golden rule of store procedure selection is to make sure the first selected data set is the smaller one.\u00a0 When a cursor points to a smaller data set, the loop count will be fewer and performance is typically better.\u00a0 The example I gave above improved from 19.5 hours to 6 only by switching the order of two nested select statement.<\/li>\n<li>As a team leader, you need to have real assessment for your team members&#8217; capabilities.\u00a0 Some people might consider this as micro-management, however, I found it a super common scenario.\u00a0 One good way to have an idea about that is to talk to your team members and see what he\/she plans to deal with the issues.\u00a0 If there&#8217;s no plan, or the execution\/executability of the plan is questionable, you&#8217;ll need a plan B.<\/li>\n<li>Customers and PMs usually are trapped in the myth of scalability: they demand things that have far more capacity than needed, or are super flexible that can perform all kinds of ridiculous magic.\u00a0 It&#8217;s important to bring them down to the earth and get the job done.<\/li>\n<li>Most frustrations come from the issue of &#8220;real requirements&#8221;.\u00a0 In many cases, the performance issue is just a product of miserable management, poor communications, political complexity, or the combination of these craps.\u00a0 For example, if two VPs of your customer&#8217;s company ask for technically conflicting features, what will you do?\u00a0 One way is to wait another five years for Moore&#8217;s Law to defeat them by raw computation power.\u00a0 Sometimes we just need little help from very higher ups to get the deal settled.<\/li>\n<li>Many people learned the idea that improvement of algorithm is more efficient than optimizing the code.\u00a0 However, this idea is based on the assumption that the original algorithm is implemented with quality code.\u00a0 Please make sure the code is quality code before wasting time to figure out\u00a0 better faster fancier algorithms.\u00a0 Lame code can screw the best algorithm on the planet without any problem.<\/li>\n<li>If you work with a gigantic team, it is almost fated that the product of your team will be slow due to the nature of bureaucracy.\u00a0 It&#8217;s purely a management problem and need courage and luck to overcome.<\/li>\n<\/ul>\n<p>Shortening waiting time typically is not related to technical issues, unless the design is bad from the very beginning, or the customer&#8217;s network infrastructure is not capable.\u00a0 Most solutions involve psychological effects, or perceptual performance per se.\u00a0 For example, I&#8217;ve encountered that my customer complains our report generating program is too slow, because it takes 5 minutes to generate a 50-page report.\u00a0 Okay.\u00a0 Later I give them another version, with a dialog showing a progress bar and flashing text regarding to the progress of report generation, and the customer is very happy about it.\u00a0 Guess what?\u00a0 The new program takes 7 minutes to generate the same 50-page report \ud83d\ude42\u00a0 Well, the trick is very simple:\u00a0user feel that things are &#8220;moving&#8221; if they see a responsive UI instead of a stalled one.<\/p>\n<p>By the way, in my previous article about the myth of memory usage, we see another form of perceptual performance although it is not related to shortening waiting time.\u00a0 Tuning the perceptual performance could be tricky and need a lot of work in usability researches.\u00a0 If you do not have a usability guy covering your back, it&#8217;s time to have more chats with the customers and try to figure out what they think.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>One major blocker for a\u00a0software project to finish is unsatisfactory performance.\u00a0 Engineers always are asked to tune the performance to customers&#8217; satisfaction no matter what.\u00a0 Performance tuning itself is a very interesting topic and I&#8217;d like to share some interesting things that I&#8217;ve encountered before. Two main performance tuning targets are reducing execution time or [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/www.cchsu.com\/art-en\/wp-json\/wp\/v2\/posts\/68"}],"collection":[{"href":"https:\/\/www.cchsu.com\/art-en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cchsu.com\/art-en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cchsu.com\/art-en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cchsu.com\/art-en\/wp-json\/wp\/v2\/comments?post=68"}],"version-history":[{"count":0,"href":"https:\/\/www.cchsu.com\/art-en\/wp-json\/wp\/v2\/posts\/68\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.cchsu.com\/art-en\/wp-json\/wp\/v2\/media?parent=68"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cchsu.com\/art-en\/wp-json\/wp\/v2\/categories?post=68"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cchsu.com\/art-en\/wp-json\/wp\/v2\/tags?post=68"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}