JS++ type guarantees don’t just mean more reliable applications. They can also mean faster applications.<\/p>\n
People have expressed concern about the “conversion overhead” that comes with the JS++ type system. However, we’ll show you today that having code that varies<\/em> in type (such as JavaScript code) can be substantially slower, and even if you lose 1ms in JS++ “conversion overhead”, you may gain 10ms, 100ms, or more from typed optimizations that you can only get with JS++.<\/p>\n Here are two side-by-side benchmarks:<\/p>\n JS++: test.jspp<\/strong><\/p>\n JavaScript: test.js<\/strong><\/p>\n Specifications: Take a close look at the JS++ code and the JavaScript code. They are nearly identical except the JS++ code has types and an import statement.<\/p>\n In this particular case, JS++ is roughly 7.2% faster than JavaScript on a basic Suddenly, JS++ has jumped from being ~7% faster to being 52.2% faster.<\/p>\n First of all, without static typing, you lose correctness. The result of the above small change results in The reason this happens is because V8 optimizes \"optimistically\". When you initialize your variable to a string, V8's JIT code generator will generate code optimized for strings. However, when the type changes, V8 has to \"de-optimize\", change the variable type, convert data, and more. These are expensive operations which highlight how performance can degrade. The example we showed today involved only one variable. Imagine the performance difference in an application with thousands of variables.<\/p>\n Finally, the JS++ type system is patent-pending. I've made my case clear about patents being only used for competition<\/a>. Since most programmers immediately jump to conclusions, I will use this example: you can use a patented skateboard without getting in trouble with the law; however, you cannot make and sell a patented skateboard without getting in trouble with the law. If you're on the fence with JS++, don't expect to see our technologies in TypeScript, Flow, or any competing language any time soon. You're free to use them, and we encourage you to do so if your only criteria when selecting technologies are \"open source\" and \"unpatented.\"<\/p>\n JS++ is free, closed-source software licensed under the BSD License, and the benchmarks above can be executed with the latest JS++ 0.5.2 release.<\/p>\n","protected":false},"excerpt":{"rendered":" JS++ type guarantees don’t just mean more reliable applications. They can also mean faster applications. People have expressed concern about the “conversion overhead” that comes with the JS++ type system. However, we’ll show you today that having code that varies in type (such as JavaScript code) can be substantially slower, and even if you lose … Continue reading “Code Written in JS++ Can be Significantly Faster than the Equivalent JavaScript”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[2,15],"tags":[13],"_links":{"self":[{"href":"https:\/\/www.onux.com\/jspp\/blog\/wp-json\/wp\/v2\/posts\/278"}],"collection":[{"href":"https:\/\/www.onux.com\/jspp\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.onux.com\/jspp\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.onux.com\/jspp\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.onux.com\/jspp\/blog\/wp-json\/wp\/v2\/comments?post=278"}],"version-history":[{"count":21,"href":"https:\/\/www.onux.com\/jspp\/blog\/wp-json\/wp\/v2\/posts\/278\/revisions"}],"predecessor-version":[{"id":299,"href":"https:\/\/www.onux.com\/jspp\/blog\/wp-json\/wp\/v2\/posts\/278\/revisions\/299"}],"wp:attachment":[{"href":"https:\/\/www.onux.com\/jspp\/blog\/wp-json\/wp\/v2\/media?parent=278"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.onux.com\/jspp\/blog\/wp-json\/wp\/v2\/categories?post=278"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.onux.com\/jspp\/blog\/wp-json\/wp\/v2\/tags?post=278"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\r\nimport System;\r\n\r\ndouble t = (new Date).getTime();\r\nstring z;\r\nfor (int i = 0; i < 5000000; ++i) {\r\n\tz += i.toString();\r\n}\r\nConsole.log((new Date).getTime() - t);\r\n<\/pre>\n\r\n$ time node test.jspp.js\r\n484\r\n\r\nreal\t0m0.537s\r\nuser\t0m0.496s\r\nsys\t0m0.100s\r\n$ time node test.jspp.js\r\n487\r\n\r\nreal\t0m0.536s\r\nuser\t0m0.500s\r\nsys\t0m0.096s\r\n$ time node test.jspp.js\r\n488\r\n\r\nreal\t0m0.536s\r\nuser\t0m0.508s\r\nsys\t0m0.088s\r\n$ time node test.jspp.js\r\n486\r\n\r\nreal\t0m0.534s\r\nuser\t0m0.480s\r\nsys\t0m0.116s\r\n$ time node test.jspp.js\r\n484\r\n\r\nreal\t0m0.533s\r\nuser\t0m0.496s\r\nsys\t0m0.096s\r\n<\/pre>\n
\r\nvar t = (new Date).getTime();\r\nvar z = \"\";\r\nfor (var i = 0; i < 5000000; ++i) {\r\n z += i.toString();\r\n}\r\nconsole.log((new Date).getTime() - t);\r\n<\/pre>\n\r\n$ time node sample.js \r\n523\r\n\r\nreal\t0m0.575s\r\nuser\t0m0.572s\r\nsys\t0m0.076s\r\n$ time node sample.js \r\n518\r\n\r\nreal\t0m0.561s\r\nuser\t0m0.556s\r\nsys\t0m0.072s\r\n$ time node sample.js \r\n524\r\n\r\nreal\t0m0.572s\r\nuser\t0m0.544s\r\nsys\t0m0.092s\r\n$ time node sample.js \r\n521\r\n\r\nreal\t0m0.565s\r\nuser\t0m0.560s\r\nsys\t0m0.076s\r\n$ time node sample.js \r\n519\r\n\r\nreal\t0m0.563s\r\nuser\t0m0.540s\r\nsys\t0m0.088s\r\n<\/pre>\n
\nCore i7-4790k
\nLinux x64 (Debian)
\n32gb RAM
\nNode.js v.7.9.0 (Google V8)
\nJS++ v.0.5.2<\/p>\ntoString()<\/code> benchmark. We do some special things under the hood here, but it should be clear that even with the perceived<\/em> overhead of JS++ conversions and<\/em> the much heavier overhead of auto-boxing<\/a>, JS++ code is still noticeably faster. However, the topic of today's post is not about toString()<\/code>. If we slightly change the JavaScript code:<\/p>\n\r\nvar t = (new Date).getTime();\r\nvar z; \/\/ variable is no longer initialized to string\r\nfor (var i = 0; i < 5000000; ++i) {\r\n\tz += i.toString();\r\n}\r\nconsole.log((new Date).getTime() - t);\r\n<\/pre>\n\r\n$ time node sample.js \r\n735\r\n\r\nreal\t0m0.779s\r\nuser\t0m0.804s\r\nsys\t0m0.072s\r\n$ time node sample.js \r\n735\r\n\r\nreal\t0m0.783s\r\nuser\t0m0.784s\r\nsys\t0m0.092s\r\n$ time node sample.js \r\n749\r\n\r\nreal\t0m0.794s\r\nuser\t0m0.824s\r\nsys\t0m0.088s\r\n$ time node sample.js \r\n742\r\n\r\nreal\t0m0.787s\r\nuser\t0m0.788s\r\nsys\t0m0.092s\r\n$ time node sample.js \r\n738\r\n\r\nreal\t0m0.782s\r\nuser\t0m0.808s\r\nsys\t0m0.064s\r\n<\/pre>\n
\"undefined0123...\"<\/code> rather than \"0123...\"<\/code>. Therefore, while it may not be the best benchmark, it illustrates the point. Besides losing correctness, the drop in performance is substantial when types change. You often see JavaScript code written where the type constantly changes, and you can see the cost of this negligence compared to JS++.<\/p>\n