2026-09-20T15:03:14Z https://www.ideals.illinois.edu/oai-pmh

oai:www.ideals.illinois.edu:2142/49706 2023-07-11 col_2142_5131 col_2142_10761 com_2142_5130 com_2142_10755 com_2142_234

Marinov, Darko Lu, Shan Marinov, Darko Lu, Shan Torrellas, Josep Xie, Tao Nistor, Adrian 2014-05-30T17:05:45Z 2014-05-30T17:05:45Z 2016-09-22T20:59:12Z 2014-05 2014-05-30T17:05:45Z 2014-05 Software performance is critical for how end-users perceive the quality of software products. Performance bugs---programming errors that cause performance degradation—lead to poor user experience and low system throughput. Despite advances in profiling techniques, performance bugs still escape in production runs. There are two key reasons why performance bugs are not effectively detected during in-house testing. First, there is little available data about how performance bugs are discovered, reported, and fixed in practice. Such data is required when designing effective techniques for addressing performance bugs. Second, the current techniques for detecting performance bugs detect only slow computation and do not address other important parts of the testing process, such as automated oracles or bug fixing. This dissertation makes three contributions. The first contribution is a study of how performance bugs are discovered, reported to developers, and fixed by developers, and how these results compare with the results for non-performance bugs. The study considers performance and non-performance bugs from three popular code bases: Eclipse JDT, Eclipse SWT, and Mozilla. First, we find little evidence that fixing performance bugs has a higher chance to introduce new functional bugs than fixing non-performance bugs, which implies that developers may not need to be over-concerned about fixing performance bugs. Second, although fixing performance bugs is about as error-prone as fixing non-performance bugs, fixing performance bugs is more difficult than fixing non-performance bugs, indicating that developers need better tool support for fixing performance bugs and testing performance bug patches. Third, unlike many non-performance bugs, a large percentage of performance bugs are discovered through code reasoning, not through users observing the negative effects of the bugs (e.g., performance degradation) or through profiling. The result suggests that techniques to help developers reason about performance, better test oracles, and better profiling techniques are needed for discovering performance bugs. The second contribution is TODDLER, a novel automated oracle for performance bugs, which enables testing for performance bugs to use the well established and automated process of testing for functional bugs. TODDLER reports code loops whose computation has repetitive and partially similar memory-access patterns across loop iterations. Such repetitive work is likely unnecessary and can be done faster. TODDLER was implemented for Java and evaluated on 9 popular Java codebases. The experiments with 11 previously known, real-world performance bugs show that TODDLER finds these bugs with a higher accuracy than the standard Java profiler. TODDLER also found 42 new bugs in six Java projects: Ant, Google Core Libraries, JUnit, Apache Collections, JDK, and JFreeChart. Based on the corresponding bug reports, developers so far fixed 10 bugs and confirmed 6 more as real bugs. The third contribution is LULLABY, a novel static technique that detects and fixes performance bugs that have non-intrusive fixes likely to be adopted by developers. Each performance bug detected by LULLABY is associated with a loop and a condition. When the condition becomes true during the loop execution, all the remaining computation performed by the loop is wasted. Developers typically fix such performance bugs because these bugs waste computation in loops and have non-intrusive fixes: when some condition becomes true dynamically, just break out of the loop. Given a program, LULLABY detects such bugs statically and gives developers a potential sourcelevel fix for each bug. LULLABY was evaluated on real-world applications, including 11 popular Java applications (e.g., Groovy, Log4J, Lucene, Struts, Tomcat, etc) and 4 widely used C/C++ applications (Chromium, GCC, Mozilla, and MySQL). LULLABY finds 61 new performance bugs in the Java applications and 89 new performance bugs in the C/C++ applications. Based on the corresponding bug reports, developers so far have fixed 51 and 65 performance bugs in the Java and C/C++ applications, respectively. Most of the remaining bugs are still under consideration by developers. Item withdrawn by Laura Spradlin (lspradl2@illinois.edu) on 2014-04-02T19:41:40Z Item was in collections: University of Illinois Theses & Dissertations (ID: 1) No. of bitstreams: 1 Nistor_Adrian.pdf: 468539 bytes, checksum: 3fbbf2e4e2981d9f99af2bcbcedd968d (MD5) Made available in DSpace on 2014-05-30T17:05:45Z (GMT). No. of bitstreams: 2 Adrian_Nistor.pdf: 468622 bytes, checksum: acee72505c484b9f79a0ddd4f036e71b (MD5) license.txt: 4062 bytes, checksum: 58f3e9a947ad0fe171d4fcad73dedfe7 (MD5) Item marked as restricted to the 'UIUC Users [automated]' Group (id=2) by Seth Robbins (robbins.sd@gmail.com) on 2014-05-30T17:09:45Z Item is restricted until 2016-05-30T17:09:03Z Restriction data tranferred 2014-07-01T11:38:50-05:00 Original Data Group with Access UIUC Users [automated] Release Date: 2016-05-30 12:09:03 UTC Reason: Author requested U of Illinois access only (OA after 2yrs) in Vireo ETD system U of I Only Restriction Lifted for Item 49757 on 2016-09-22T20:59:12Z. http://hdl.handle.net/2142/49706 en Copyright 2014 Adrian Nistor Performance bugs Understanding, detecting, and repairing performance bugs text Computer Science 1434 Computer Science 0112 University of Illinois at Urbana-Champaign Dissertation Ph.D. PHD:Computer Science -UIUC 10KS0112PHD