Il y a des insights vraiment intéressants sur le comportement de V8 dans ce travail et la qualité du travail est vraiment impressionnante pour ce qui semble être un travail de session pour un cours. De plus, la documentation sur la définition initiale du projet, le suivi et le rapport final sont vraiment intéressants. On pourrait s'en inspirer pour nos propres projets. Erick *Instrumenting V8 to Measure the Efficacy of Dynamic Optimizations on Production Code* 4.1 Optimization has limited benefit [...] 4.2 Many optimizations diminish performance [...] 4.3Reasons for Performance Tables3 <http://www.mrcaps.com/proj/OptimizationEfficacy/site/#x1-140023>and4 <http://www.mrcaps.com/proj/OptimizationEfficacy/site/#x1-140034>summarize the interesting counters for BenchM and Gmail respectively. In general, the trend is towards more deoptimizations, stack interrupts, and compiled code as optimizations get more aggressive. Ignoring the case where optimizations don't occur, program counter to source code looks-ups also occur more often and stubs are utilized less often as optimization becomes more aggressive. The trend is towards performing notably more operations in the compiler as the amount of optimization increases. In particular, we measured the impact of increasing deoptimization. By isolating time taken for deoptimization from the profiler results, we find that foralways_opton BenchM the time required to execute deoptimization increases from 0 to7333±107profiler ticks as compared to a total of24726±193execution ticks --- a very significant component of runtime. In4.2 <http://www.mrcaps.com/proj/OptimizationEfficacy/site/#x1-130004.2>we saw that the compile-time overhead for applications like Gmail is higher than for the V8 benchmark. The question arises of which portions of the compilation process contribute to this overall overhead. We break down compilation time into its multiple phases by analyzing the contents of the profile and attributing a point in the trace to one of nine portions of the codebase. Five of these phases (Assembler, Lithium, Hydrogen, AST, and Parser) correspond to the portions in Figure1 <http://www.mrcaps.com/proj/OptimizationEfficacy/site/#x1-40011>, and three (LowLevel, Shared, and Tracing) are work that is shared between multiple parts of the compiler. Figure5 <http://www.mrcaps.com/proj/OptimizationEfficacy/site/#x1-140045>illustrates the breakdown for the three summary configurations used previously. An overall conclusion for Gmail is that much of this compilation time does not come from time spent in the optimizer. Rather, it comes from work that must be done in any case, even with the optimizing compiler turned off entirely. Of all the time allocation, the parser is the largest contributor. Though initially surprising, this is sensible in light of the much larger size of the Gmail source: based on internal counters, the parser handles over 14 times as much code in Gmail than in BenchM. While compilation overhead for BenchM does increase significantly as a result of time spent in the optimization path, the total overhead is small compared to the decrease in JavaScript execution time it produces. These results also support the running observation that the opportunity for optimization is limited in real-world applications. http://www.mrcaps.com/proj/OptimizationEfficacy/site/