I modified V8 (specifically src/heap.cc) to keep track of the total memory allocation, and added JS callable primitives to get the current time and space usage.
Here's the time and space taken by each compilation phase, for compiling the runtime, stdlib, and Tachyon itself:
runtime: ========== Parsing (0.14 s, 8.98 MB allocated) ========== IR generation (0.24 s, 22.95 MB allocated) ========== IR lowering (1.02 s, 84.80 MB allocated) ========== Machine code generation (3.33 s, 213.03 MB allocated) ========== Machine code linking (0.05 s, 5.19 MB allocated)
stdlib: ========== Parsing (0.08 s, 2.94 MB allocated) ========== IR generation (0.10 s, 13.05 MB allocated) ========== IR lowering (1.02 s, 77.43 MB allocated) ========== Machine code generation (5.02 s, 233.63 MB allocated) ========== Machine code linking (0.09 s, 7.38 MB allocated)
Tachyon compiler: ========== Parsing (1.04 s, 88.50 MB allocated) ========== IR generation (6.18 s, 571.99 MB allocated) ========== IR lowering (47.01 s, 2585.86 MB allocated) ========== Machine code generation (460.40 s, 7372.72 MB allocated) ========== Machine code linking (5.01 s, 251.20 MB allocated)
The percentage breakdown for the Tachyon compiler is:
Time: 0% Parsing 1% IR generation 9% IR lowering 89% Machine code generation 1% Machine code linking
Memory allocation: 1% Parsing 5% IR generation 24% IR lowering 68% Machine code generation 2% Machine code linking
We can see that the machine code generation is the part of the compiler taking up most of the time and space. In terms of space, the IR lowering is also a heavy consumer.
So we should focus our code improvement efforts on those parts.
Should I also break down the machine code generation phase into subphases to see which part is causing the greatest performance problem? If so which?
Marc