Good day. Our team, which is engaged in the creation of Java courses on Hexlet , decided to start translating articles that we found very interesting. Being engaged in this business, we found that on Habré did not yet run through the translation of the most magnificent article entitled: " Why are mobile web applications so slow? ". It is the translation of its part that we bring to your attention today. The article is not very new and even more surprised that Habré did not meet its translation, but it seems relevant (in its ideas) to this day, although, of course, many benchmarks are outdated. If the Habra community liked the beginning, then we will publish the second part, as well as begin publishing translations of other articles that we found very interesting and not presented at Habré.

My previous article, where I argued that mobile web applications are slow , has caused an unusually many interesting conversations. A discussion ensued, both online and in real life, but, alas, it was not as based on facts as I would like.
')
In this regard, in this post I am going to present real evidence to discuss this problem, and not just to arrange an unsubstantiated shouting. You will see key points, hear expert opinions, and even read crystal-clear journal articles on this topic. This post contains over 100 quotes, and this is not a joke. I do not guarantee that this article will convince you, or that absolutely all the information presented does not contain errors (this is not possible for an article of this size), but I can guarantee that this is the most complete and detailed analysis of the opinion of many iOS developers that mobile Web applications work and will work slowly in the foreseeable future.

I warn you: this is a very boring and long article of almost 10 thousand words. This is the format. Recently, I prefer good, not popular articles . This is my attempt to write a good article, as well as put into practice what I previously called for: to encourage an interesting discussion based on facts, and to refrain from witty comments.

I am writing this article partly for the reason that this topic is discussed endlessly (in the form of exchanging prickly phrases). This is not another article on a hackneyed topic, so if you are looking for a 30-second chatter in the spirit of "No, really web applications - sucks!" "No, not sucks," then this article is not for you. The web is full of such discussions in the spirit of "Oh, stop it, I can not breathe, please stop, so many opinions and few facts," etc. On the other hand, as far as I can judge, nowhere to find a detailed, informative and adequate discussion of this issue . This may seem like a very stupid idea, but this article represents my attempt to calmly discuss a topic that has already spawned completely meaningless banal disputes filled with a flame. My position is this: the problem is rather that people who are able to more adequately discuss the issue, do not participate in the discussion, and not in the very subject of discussion. I think we will find out if this is so.

So, if you want to find out what kind of insanity has found on your fellow developers who continue to write their own unfortunate applications on the eve of the already obvious web revolution, or to find out something else , add this page to your bookmarks, brew a cup of coffee, find free evening, sit in a comfortable chair, and, behold, we are both ready for discussion.

Short review

In my previous post, I argued with the example of SunSpider that, to date, mobile web applications are slow.

“Of course, if by“ web application ”you mean“ a website with one or two buttons, ”then you can send all the miserable performance tests like SunSpider to hell. If you mean "fast text processing, photo editing, local storage and animation between screens," then you should not do this with a mobile application on ARM, unless you are a suicide. "

This article is really worth reading, but I will still show you a performance test:

In general, this comparative test is criticized from three positions:

1. It's no secret that the JS code is slower than its own code: everyone learned about this in CS1 when comparing, JIT and interpreted languages ​​were compared. The question is how much its slow work affects the programs you write, and such performance tests cannot solve this problem in one way or another.
   
2. Yes, JS is slower, and it matters, but its performance is constantly increasing, and once we notice for the first time that the difference in speed is already insignificant, so start investing in JS right now.
   
3. I am writing a server program in Python / PHP / Ruby, and it makes no difference to me that you are driving there. I know that my servers are faster than your mobile devices, but in fact, it’s not difficult for me to serve X000 users using the actually interpreted language, but can you guys imagine how to serve one user in a language with a high-performance compiler JIT? How hard can it be?
   

I set myself a rather ambitious goal: to refute all three claims in this article. Yes, JS is slow, and it really matters. No, in the near future it will not be noticeably faster. No, your experience with server programming will not prepare you properly to “start small” and competently talk about the performance of mobile applications.

The main problem is that all articles on this topic rarely give figures showing how slow the JS code works , or some really useful comparison criterion is given (slowly ... compared to what? ). In order to fix this, I will give in this article not one , but three equivalent performance for JavaScript. Therefore, I will not only refute the “old songs” about the “slow JS work”, but also show in numbers how slow it works and compare it with many indicators from real programming, so that when you encounter the need to choose a platform, you could calculate quickly and determine if javascript is effective for solving your particular problem.

All this is good, but how to compare the performance of JS with the performance of your own applications?

Good question. To answer it, I chose an arbitrary benchmark from the Benchmarks Game. Then I found an older C program that performs the same test (an older one, since the new ones have many details depending on x86). After that, I compared the Nitro with LLVM on my proven iPhone 4S. All this code can be found on GitHub .

All this is very arbitrary, but the code that you execute in real life is just as arbitrary. If you need a better experiment, well, experiment. This is just my experiment, since there are no other experiments to compare LLVM and Nitro.

Anyway, in this synthetic benchmark, LLVM performance is consistently 4.5 times faster than Nitro:

So, if you are wondering how much faster the function is limited by the processor in its own code as compared to Nitro JS, the answer will be “about 5 times”. This result generally coincides with the results of the Benchmarks Game with x86 / GCC / V8, according to which , GCC / x86 as a whole is 2 - 9 times faster than V8 / x86. Thus, the result, apparently, is close to the truth and does not depend on whether you use ARM or x86.

But is 1/5 of performance not enough?

Enough for x86. In fact, how much does the processor render the table visualization? Not so much. The problem is that ARM is not x86.

According to GeekBench , a comparison of the latest MBP model with the latest iPhone model showed a factor of 10, so everything is fine, the tables are not that heavy. You can work with a capacity of 10%. And you still want to divide it into five? Bravo, buddy! Now we have a performance of 2% of the desktop computer (I arbitrarily operate with units, but we are dealing with the order of magnitudes. Okay, it’s fine).

Good, but how difficult is word processing really ? Is it not possible to do this on an m68k-type processor, adding another processor to it? Well, this question can be answered. You may not remember, but real-time interaction with Google Docs was not really just a launch function. They rewrote a lot of things by April 2010. Let's see what browser performance was in April 2010 .



Judging by the graphics, it is clear that the iPhone 4S is absolutely not comparable with web browsers in the era of interaction with Google Docs in real time. However, it can compete with IE8, with which I congratulate him.

Consider another serious JavaScript application: Google Wave. According to Google , Wave never supported IE8, since it worked too slowly.



^{(To use Google Wave in Internet Explorer, you must install the Google Chrome Frame Browser plugin. Alternatively, you can use one of the following browsers: Google Chrome, Safari 4, Firefox 3.5. If you want to continue working at your own risk, go to the next step).}

See how much faster these browsers are than the iPhone 4S?

See how all supported browsers show results below 1000, and the one that showed the result of 3800, is excluded due to low speed? iPhone shows a result of 2400. Like IE8, it doesn’t work fast enough to launch Wave.

Clarify: you can work in real time on a mobile device, but you cannot do it in JavaScript . The performance difference between native and web applications is comparable to the performance difference between FireFox and IE8. This is too big a difference for serious work .

But I thought that the performance of the V8 / modern JS is almost as good as the C!

It all depends on what is meant by “almost.” If your C program runs in 10 ms, then a 50 ms speed in a JavaScript program will be “almost” equal to C. But if your C program runs in 10 seconds, then 50 seconds of a JavaScript program for most ordinary people is clearly not will be almost the speed of C.

Hardware aspect

Still, a factor of 5 is acceptable for x86 , primarily because x86 is 10 times faster than ARM. There is plenty of room to maneuver. This solution is clearly intended only to speed up ARM 10 times, so that it is comparable to x86, and then you can achieve performance like JS on a desktop computer without any extra effort!

Whether this will work depends on your belief in Moore's law regarding trying to charge a chip with a 3-ounce battery. I am not a hardware engineer, but once I worked at a large semiconductor manufacturing company, and its employees told me that at present, productivity depends mainly on the process (i.e., the value measured in nanometers). The impressive performance of the iPhone 5 is mostly due to a reduction in the process from 45 nm to 32 nm, that is, a decrease of about a third, but to repeat this, Apple would have to shrink the process technology to 22 nm.

Just for reference: Intel’s 22nm x86 Atom Bay Trail version does not currently exist . Intel had to invent a completely new version of the conductor , since the standard version did not work on a scale of 22 nm. Do you think they will sell the ARM license for it? Think again. In the world, only a few 22nm integrated circuit manufacturing enterprises are planned to be seriously built , and most of them are controlled by Intel.

In fact, ARM, apparently, tends to reduce the process technology to 28 nm or so (see A7), and Intel meanwhile tends to 22 nm, and perhaps even to 20 nm. If we consider only the hardware aspect, then it seems to me much more likely that the x86 chip with x86 class performance will be used in the smartphone much earlier than it will be possible to reduce the ARM chip with x86 class performance.

A note from a former Intel engineer who sent me an email:

“I’m a former Intel engineer who worked on a line of microprocessors for mobile devices, and then at Atoms. Anyway, in my incredibly biased opinion, it will be easier to install x86 on a “feature set” phone from larger cores than ARM can catch up on x86 performance by developing these functions from scratch. ”

A note from a former Robotics engineer who emailed me:

“You are absolutely right that they will slightly increase performance, and that Intel may have a faster processor for mobile devices in a few years. In fact, at present, mobile processors are experiencing the same limitation as desktop processors when they reach 3 GHz: a further increase in clock frequency is impractical without a fundamental increase in power. This is also true for the following process nodes, although they should be able to slightly increase IPC (perhaps by 10-20%). When they faced this limitation, dual-core and quad-core processors for desktop computers were launched, but mobile systems on a chip are already dual-core and quad-core, so it will not be easy to achieve acceleration. ”

Thus, in the end, Moore's law may be true, but only in that a whole mobile ecosystem is required for the transition to x86. This is not to say that this is impossible; it has already been done before. True, this was in an era when the annual sales volume was about a million units , and now it is selling 62 million a quarter . This was done using a ready-made virtualization environment that could mimic the old architecture at a rate of about 60% . Meanwhile, the performance of modern hypothetical search engines virtualization for optimized (O3) code is close to 27%.

If you believe that eventually JavaScript will come to this, then the most effective way will be to improve the hardware. Either Intel will have a viable chip in 5 years (probably) and Apple will change the concept (unlikely), or ARM will be out of the game over the next decade (talk to 10 hardware engineers and you will get 10 different opinions about the likelihood of this option). However, a decade is a long time for a project that can be crowned with success .

I am afraid that my knowledge in the field of equipment ends there. I can tell you only one thing: if you want to believe that ARM will close the gap with x86 in the next 5 years, first of all you need to find someone who is working on ARM or x86 (that is, a person who really has the knowledge) so that he agrees with you. To write this article, I consulted with many qualified engineers, and they all refused to officially voice such a position, so it seems to me that there is nothing good in it.

Program aspect

Here, many competent software engineers come to a standstill. They think like this: JavaScript has become faster, and will accelerate in the future!

The first part of this statement is true. JavaScript has become much faster. However, it has already reached its peak and in the future its speed will not increase significantly.

Why? First of all, most of the improvements in JavaScript in its entire history actually concerned the hardware . Here is what Jeff Atwood writes :

“I found that JavaScript performance improved significantly from 1996 to 2006. The fact that Web 2.0 is built on the basis of JavaScript has become possible mainly due to decisive performance improvements according to Moore's law. ”

If you associate the JS acceleration with the hardware as a whole, then an improvement in the performance of (hardware) JS is not a prerequisite for improving the performance of programs in the future . That is why, if you want to believe that JS will accelerate, today it will most likely be due to the acceleration of the equipment, since this is evidenced by the historical trend.

What about JIT, V8, Nitro / SFX, TraceMonkey / IonMonkey, Chakra and the rest? Well, at the time of release, they were something significant, although not as significant as you think. V8 was released in September 2008. At about the same time, I dug out a copy of Firefox 3.0.3:

Understand me correctly, the performance increase by 9 times cannot be ignored, after all, this number is almost equal to the difference between ARM and x86. Thus, the difference in performance between Chrome 8 and Chrome 26 remains at the same level, since nothing has happened since 2008. Other browser makers made up for lost time (someone is faster, someone is slower), but no one has since really increased the speed of the processor code itself.

Does javascript performance improve?

Here's Chrome v8 on my Mac (the earliest version that still works, December 2010), but v26 .


Do not see the difference? This is because there is none. Recently, nothing of the utmost importance has occurred with JavaScript, limited processor.

If the network seems to you faster than in 2010, then this is probably due to the fact that you are working on a faster computer, and the improvements in Chrome have nothing to do with it.

Note. Some smart people have noted that today, SunSpider is not a good test of performance (at the same time, they refused to provide any actual numbers). To start a meaningful discussion, I ran Octane (a Google test) on older versions of Chrome, and it showed some improvement:


In my opinion, improving the performance acquired during this period is not enough to confirm the statement that JS bridges the gap in the foreseeable period of time. Nevertheless, I must admit that I overestimated this case, since something does happen in JavaScript, limited by the processor. Nevertheless, for me, these numbers confirm a big hypothesis: these improvements are not at all those values ​​that can bridge the gap with their own code in the foreseeable future. It is necessary to improve everything by 2 - 9 times in order to compete with LLVM. These improvements are good, but not to that extent. End notes.

The fact is that the idea of ​​using JIT in JavaScript originated 60 years ago. It was followed by 60 years of research and literally thousands of implementations for all programming languages ​​to prove that it was a good idea. Now that we have done this, we have exhausted the ideas of 60 years ago. All friends, the show is over. We may be able to come up with another good idea over the next 60 years.

But Safari seems to be faster than before?

If this is true, then why do we constantly hear about all the great performance improvements in javascript? Almost every week someone advertises a huge acceleration in any test. Here, Apple announces a stunning acceleration of 3.8 times in JSBench:



So Safari 7 is 3.8 times faster than other browsers?

Perhaps for the convenience of Apple, information about this version of Safari has not been disclosed, so that no one can publish independent data on the speed of Safari. However, let me make a number of thoughts on this application, based only on publicly available information.

First of all, I was interested in the fact that Apple reports in JSBench open reports about much better results than in reports about traditional tests like SunSpider. Now some interesting people are behind JSBench, for example, Brendan Eich, the creator of JavaScript, but unlike traditional tests, a program is not written in JSBench, where the decisive role is played by integers or something like that. Instead, JSBench automatically rakes up everything that Amazon, Facebook and Twitter present, and creates tests from all of this. If you write a web browser that (let's say honestly) most people use to visit Facebook, I imagine how useful it is to have a test exclusively for Facebook. On the other hand, if you write a program for working with tables, a game or an application for filtering images, it seems to me that the traditional test with its arithmetic of integers and hashing of md5 will be useful to you much more than monitoring the speed of the Facebook analytic code.

Another important fact is that, according to Apple, performance improvement in SunSpider does not always mean improvement in anything else. In the same document that represents Apple’s preferred test, Eich and others write the following:

“The diagram clearly shows that, according to SunSpider, the performance of Firefox version 3.6 has increased 13 times compared to version 1.5. However, if you look at the improvements on Amazon, they look much more modest - 3 times. What is even more interesting, over the past two years, the improvements on Amazon have leveled off. Apparently, some optimizations that work well on the Sun Spider are ineffective on Amazon. ”

In the same document, the creator of JavaScript and one of the leading architects of Mozilla openly admits that nothing has happened to the Amazon site’s JavaScript performance over the past two years, and nothing incredibly exciting has ever happened. This suggests that marketers simply impose their products for years.

Continuing the theme, they essentially say that Amazon’s performance testing is a better means of predicting Amazon’s performance than SunSpider’s performance testing [uh-uh ... obviously ...], therefore, it is well suited for web browsers that are used to visit Amazon. However, all this does not help to write an application for photo processing.

But in any case, based on open information, I can say that Apple's statements about the performance increase by 3.8 times do not always mean something useful to you. I can also say that if I had tests that refute Apple’s claims of superiority over Chrome, I would not be allowed to publish them.

So let's end this section with the following conclusion: if someone has a graph showing that their web browser is faster, this does not mean that JS as a whole becomes faster.

We hope that you will like the article as much as we liked it in due time. If so, then soon the second part of the translation is waiting for you.