Institutionen För Datavetenskap Department of Computer and Information Science
Total Page：16
File Type：pdf, Size：1020Kb
Institutionen för datavetenskap Department of Computer and Information Science Final thesis Performance Analysis of JavaScript by Fredrik Smedberg LIU-IDA/ LITH-EX-A--10/020-SE 2010-05-17 Linköpings universitet Linköpings universitet SE-581 83 Linköping, Sweden 581 83 Linköping Linköping University Department of Computer and Information Science Final Thesis Performance Analysis of JavaScript by Fredrik Smedberg LIU-IDA/LITH-EX-A--10/020-SE 2010-05-17 Supervisor: David Byers Examiner: Nahid Shahmehri Summary Figure 1: Development of JavaScript Performance over Time In the last decade, web browsers have seen a remarkable increase of performance, especially in the JavaScript engines. JavaScript has over the years gone from being a slow and rather limited language, to today have become feature-rich and fast. It’s speed can be around the same or half of comparable code written in C++, but this speed is directly dependent on the choice of the web browser, and the best performance is seen in browsers using JIT compilation techniques. Even though the language has seen a dramatic increase in performance, there’s still major problems regarding memory usage. JavaScript applica- tions typically consume 3-4 times more memory than similar applications written in C++. Many browser vendors, like Opera Software, acknowledge this and are currently trying to optimize their memory usage. This issue is hopefully non-existent within a near future. Because the majority of scientific papers written about JavaScript only compare performance using the industry benchmarks SunSpider and V8, this thesis have chosen to widen the scope. The benchmarks really give no information about how JavaScript stands in comparison to C#, C++ and other popular languages. To be able to compare that, I’ve implemented a GIF decoder, an XML parser and various elementary tests in both JavaScript and C++ to compare how far apart the languages are in terms of speed, memory usage and responsiveness. 1 Thanks to Thanks to Opera Software and Link¨oping University that made this the- sis possible. Special thanks to Nicklas Larsson (my supervisor at Opera), Geoffrey Sneddon, James Graham, Daniel Sp˚ang, Jens Lindstr¨omand the other people at the Core division of Opera Software for answering all my silly questions. I also want to thank Professor Nahid Shahmehri and David Byers at the ADIT division of the Department of Computer and Information Science at Link¨oping University for their guidance while writing this thesis. 2 Contents 1 Introduction 12 1.1 A Short History of the Web . 12 1.2 The Need for Increased Speed . 13 1.3 Purpose and Problem Formulation . 14 1.3.1 Questions . 16 1.3.2 The Chosen Languages . 16 1.4 OutlineofthisThesis ...................... 17 2 A Short Introduction to JavaScript 18 2.1 TheBirth............................. 18 2.2 Language Design . 18 2.3 The Virtual Machine . 19 2.4 Strategies Towards Speed . 20 3 Areas of Interest 21 3.1 How Performance gets Affected . 21 3.2 The Amount of Code and its Influence on Understandability . 22 3.3 Memory Leaks . 22 3.4 Portability and Reusability . 22 3.5 Development Tools . 23 3.6 When,WhereandhowOften . 23 3.7 Software Language . 23 4 Related Work 24 4.1 Comments on Sun Microsystems Research . 24 4.1.1 Extremely Tolerant . 24 4.1.2 Lack of Modularity and Functionality . 25 4.1.3 Memory Management . 25 4.2 Comments on two Research Papers from Microsoft . 25 4.3 Comments on Research made by the University of Michigan . 27 4.3.1 Memory consumption comparison . 28 4.3.2 CPU Usage . 29 4.3.3 Responsiveness . 29 3 4.3.4 Start-up time . 30 4.3.5 JavaScript Benchmark . 30 4.4 Comments on a Paper from the University of Calgary . 31 4.4.1 Start-up time . 31 4.4.2 SunSpider Benchmarks . 32 5 Methodology 33 5.1 Method .............................. 33 5.1.1 The GIF Image Decoder . 34 5.1.2 The XML Parser . 34 5.1.3 Individual Tasks . 34 5.1.4 JPEG Encoder . 35 5.1.5 Industry Benchmarks . 35 5.1.6 Implementation Method-flow . 35 6 Implementation 37 6.1 Implementing an Image Decoder . 37 6.1.1 Purpose . 37 6.1.2 Choosing a Suitable Format . 38 6.1.3 Architecture and Design . 38 6.1.4 Implementation . 39 6.1.5 How Often is the GIF Decoder Used? . 40 6.1.6 Development Utilities . 40 6.1.7 Discovered Problems Along the Way . 41 6.1.8 Profiling and Optimization . 42 6.2 Parsing XML . 48 6.2.1 Purpose . 48 6.2.2 Choosing a Suitable Format . 48 6.2.3 Architecture and Design . 48 6.2.4 Implementation . 48 6.2.5 How Often is the XML Parser Used? . 48 6.2.6 Development Utilities . 49 6.2.7 Profiling and Optimization . 49 6.3 Low-level Tasks . 49 6.3.1 Purpose . 49 6.3.2 Architecture and Design . 49 6.3.3 Implementation . 49 6.3.4 Profiling and Optimization . 49 7 Results 50 7.1 Motivation . 50 7.2 OutlineoftheResults ...................... 51 7.3 InterestingPerformanceResults. 52 7.3.1 Historic Development . 52 4 7.3.2 JPEGencoding...................... 52 7.3.3 GIFdecoding....................... 53 7.3.4 Working with Strings and Running Regular Expressions 55 7.4 Time................................ 56 7.4.1 Time Spent on Rewriting the C++ Code to JavaScript 56 7.4.2 Time Spent on Writing a XML Parser . 56 7.4.3 Time Spent on Modifying the Shootout Source Code . 56 7.5 Multitasking and Responsiveness . 57 7.5.1 Parse ’n Load . 57 7.5.2 Cooperative multitasking . 57 7.6 ElementaryTests......................... 59 7.7 TestSuites ............................ 65 7.7.1 V8 Test Suite . 65 7.7.2 SunSpider Benchmark . 66 8 Discussion 70 8.1 Historic Development . 70 8.2 Performance of the GIF Decoder and JPEG Encoder . 71 8.3 XML Parsing . 73 8.4 Parse ’n Load . 74 8.5 OtherResults........................... 74 8.6 Development Tools . 74 8.7 Some Last Thoughts . 75 9 Conclusion 78 9.1 Is the Performance of the Software Affected? . 78 9.2 Has the Code Become Easier to Comprehend? . 78 9.3 What Development Utilities Exist and What’s Their Impact ontheDevelopment?....................... 78 9.4 When and Where is it Motivated to use JavaScript? . 79 9.5 How Often is the Code Used, Every Millisecond, Minute, Hour or Day? . 79 9.6 Conclusion . 79 10 Future Work 80 11 Appendix A 82 11.1 LZW decompressor written in Python . 82 12 Appendix B 83 12.1 GIF Files Used During Implementation . 83 12.1.1 GifSample . 83 12.1.2 OpenDNS Logo . 84 12.1.3 Colored Small Test Image . 84 5 12.1.4 i-Bench Transparent GIF . 84 12.1.5 Large Colored Sinus Curve . 85 12.2 Strange Results when Decoding GIF . 85 12.2.1 Missing Color Channels . 85 12.3 PNG File Used with the JPEG Encoder . 86 12.3.1 Pool table . 86 13 Appendix C GIF Format Explanation 87 13.1 Defining the Grammar . 87 13.1.1 Grammar . 87 13.1.2 Example . 88 13.2 GIF Data Format . 88 13.2.1 Header . 88 13.2.2 Logical Screen Descriptor . 88 13.2.3 Global Color Table . 90 13.2.4 Image Descriptor . 90 13.2.5 Local Color Table . 91 13.2.6 Table Based Image Data . 92 13.2.7 Graphic Control Extension . 92 13.2.8 Comment Extension . 94 13.2.9 Plain Text Extension . 94 13.2.10 Application Extension . 95 13.2.11 Trailer . 95 14 Appendix D AGIFDecoderwritteninC++ 96 14.1 main.c . 96 14.2 gifdecoder.c . 100 14.3 gifdecoder.h . 111 15 Appendix E Web Browser Image Decoding Performance Test 115 15.1 C++ Image Decoding Speed Test using JavaScript . 115 16 Appendix F Patterns 117 16.1 General . 117 16.1.1 NULL assignment . 117 16.1.2 Boolean values . 117 16.1.3 Changing one character . 118 16.1.4 For-loop . 118 16.1.5 Assertion . 119 16.1.6 RETURN IF ERROR . 120 6 16.1.7 OP NEWA . 120 16.1.8 op memcpy (copying of memory) . 120 16.1.9 Opera Status Code . 122 16.2 Classes . 123 16.2.1 Interfaces . 123 16.2.2 Inheritance . 123 16.2.3 Constructor . 126 16.2.4 Create (definition) . 126 16.2.5 Create (usage) . 127 16.2.6 Public variable . 127 16.2.7 Public function . 127 16.2.8 Public struct . 128 16.2.9 Private variable . ..