Why Web apps are running slow

Sunspider benchmark tests show that mobile Web applications are now generally slower to run (as shown in Figure 1). Basically, there are three main types of attitudes towards Sunspider benchmark testing.

The problem with JavaScript being slower than native code is that JavaScript is a bit slow in some ways, and it's critical to the type of software you're writing.

The speed of JavaScript does have an impact on the program, but it's getting faster, and one day it's going to get rid of "slow" hats.

I use Python/php/ruby to write server-side code, and my server runs faster than your mobile devices. But if I can support thousands of users with an interpretive language, can you think of a way to support a single user with a high-performance JIT language? How difficult is this to do?

Figure 1 The speed at which JavaScript programs run on different browsers

In this article, I will make a bold attempt to refute the three points above. JavaScript is really slow to run, and there is no tendency to be fast in the future; the experience with server-side programming may seem pretty bull, but when you try to think about the performance of mobile apps, you can't "look small". In addition, in the article on JavaScript, few people really quantify how slow it is, or provide a set of criteria. To correct this, I will provide three equivalent of JavaScript performance, so that you have an intuitive understanding of it.

Compared with the performance of the native program, what is the performance of JS?

To answer this question, I selected one of the benchmark tests from benchmarks game. Then, I found a very old C language program to perform this test. I tested the LLVM (underlying virtual machine) and Nitro with the iphone 4S. In the test, the LLVM is always 4.5 times times the speed of Nitro (as shown in Figure 2).

Since the actual running of the code is arbitrary, so this kind of experiment is very valuable, you might as well do this experiment yourself. If you're curious, "if the CPU binding function is not in Nitro JS, but in the native code, the speed will be much faster", my answer is about 5 times times faster. The answer is roughly consistent with the results of the benchmarks Game Test x86/gcc/v8 (gcc/x86 is generally v8/x86 times faster than 2~9).

Fig. 2 Results of comparison Test between LLVM and Nitro

Can the performance of native code 1/5 satisfy everyone?

How does a dense CPU render a spreadsheet? Actually it's not that hard. The problem is that arm is not x86. According to Geekbench's test results, the latest MBP compared to the latest iphone, the total factor difference is 10, so the spreadsheet rendering is no problem. But what about the word processing? Can't we do it like m68k (Motorola 68000 CPU) by binding a coordinated processor behind it? You may have forgotten that Google Docs's real-time collaboration is not a feature of its nature, which was added in April 2010 when it was massively rewritten. With this feature, the IPhone 4S is completely uncompetitive relative to the Web browser.

Let's take a look at another important JavaScript application--google Wave. Google Wave never supports IE8, because IE8 is too slow. All of the browsers supported by Google Wave (Gogle Chrome, Safari 4, FIREFOX) benchmark results are below 1000 milliseconds. The iphone's benchmark test results were 2400 milliseconds, so it couldn't run Google Wave. Here's the point: real time collaboration can be done on a mobile device, but not in JavaScript. The performance gap between native applications and Web applications is comparable to the performance gap between Firefox and IE8, which is quite a big gap for important work.

This column more highlights: http://www.bianceng.cn/webkf/tools/