Home >Web Front-end >JS Tutorial >Two sets of performance test data for eval_javascript skills
A Weibo post by @老赵 "Is the code generated by eval really inefficient? http://t.cn/zWTUBEo Contains personal attacks, please don't enter if you don't like it."
triggered the recent heated discussion about eval During the discussion, the leader @Franky and Hui Da @otakustay also gave wonderful data analysis.
I happened to have done a similar test before, so I followed suit and joined in the fun, providing two sets of data for your reference.
Update 1: Thanks to @otakustay’s guidance, in order to eliminate the impact of the eval('') call itself on the results, a new set of data A3 and B3 has been added. And retest all old data.
Update 2: Thanks to Mo Da @貘吃荍香 for the powerful Paizhuan, added 1). Test data after eval coverage of A4, B4; A5, B5; 2). A6, B6 eval aliases; 3). A7,B7 eval.call.
Test environment:
a. Machine: Intel(R) Corei7-2720 2.2Ghz (4 cores 8 threads), memory 8Gb
b. OS: Windows 7 Enterprise SP1 64-bit
c. Browser:
b.1 Google Chrome 21.0.1180.79 m
b.2 Firefox 14.0.1
b.3 IE9.0.8112.16421
d. Test method
d .1 Each use case is tested 5 times, and the minimum time is taken.
d.2 Firebug or Chrome Console was not turned on during the test. Turning on these tools will double the time, making it difficult to get the results of this use case within the effective time
Use Case A1:
We inline Call empty eval("") in the function
A组测试结果:
A1 | A2 | A3 | A4 | A5 | A6 | A7 | A1 : A2 | A1 : A3 | A1 : A4 | A4 : A5 | |
Chrome | 1612ms | 8ms | 1244ms | 897ms | 7ms | 718ms | 680ms | 201.5 | 1.3 | 1.8 | 128.1 |
Firefox | 2468ms | 69ms | 732ms | 2928ms | 134ms | 5033ms | 4984ms | 35.8 | 3.4 | 0.8 | 21.9 |
IE | 1207ms | 23ms | 233ms | 1147ms | 37ms | 148ms | 224ms | 52.5 | 5.2 | 1.0 | 31.0 |
B1 | B2 | B3 | B4 | B5 | B6 | B7 | B1 : B3 | B1 : B2 | B1 : B4 | B4 : B5 | |
Chrome | 1569ms | 134ms | 1093ms | 1022ms | 173ms | 830ms | 916ms | 11.7 | 1.4 | 1.5 | 5.9 |
Firefox | 5334ms | 1017ms | 5503ms | 5280ms | 1171ms | 6797ms | 6883ms | 5.2 | 1.0 | 1.0 | 4.5 |
IE | 3933ms | 560ms | 680ms | 4118ms | 583ms | 745ms | 854ms | 7.0 | 5.8 | 1.0 | 111.3 |
Conclusion ( is limited to CASE in the text):
1. Repeated calls to eval itself are very time-consuming, even empty eval("");
2. eval has an impact on the execution efficiency of inline functions, which varies depending on the specific environment and code;
3. We can see that no matter which browser, whether it is group A or group B, 2 and 5 have better speed. It shows that no matter how the eval of the inline function in the example is called (even if eval is overwritten by an empty function), it will still have a great impact on the operating efficiency. The inference is (black box inference, non-authoritative, probably just conjecture) that as long as eval is found in the inline function, even if the eval is an overridden empty function, all externally defined variables and other contents will be initialized in Scope Variables. to the current Scope. Similarly, eval will have a greater impact on the optimization function of the JS engine at runtime for inline functions and reduce execution efficiency.
4. To make a digression, although IE10 is not used, but IE9 is used, the performance of eval processing is very good. IE has always been criticized by developers, but its rapid growth is worthy of recognition. This example is a good proof.
A more detailed analysis of the reasons. The descriptions in the following articles are very detailed and will not be repeated again. Welcome:) Especially Mo Da...
@老赵’s 《Is the code generated by eval really inefficient? 》
@Franky’s "Popular Science on Eval"
@otakustay’s "A Brief Talk on the Influence of Eval"