At that moment, rather than a few sips of coffee running down his throat, he experiences something else rolling down from his eyes. “Sacrilege”, the boy whispers with subtle but clear hints of bitterness in his voice. ‘Slower than a coffee machine? This execution time is a bold mockery in the holy realm of programmers – who are obligated to optimize.’
Concluding that something must be done, the boy hesitates no more and quickly turns to the ‘savior’ of all coders – Google. ‘Oh thy Google, have mercy on such undignified bundling time.’ Soon after, Google blesses the boy with a Babel Precompilation feature. Too glaringly bright to even glimpse at, the boy humbly accepts the feature and never again has to wait for the code to bundle with a fresh coffee present in his mug. A few days later, still treasuring the moment of epiphany, he seeks out to teach others what he has learned in the hope that no one will ever need to suffer like he did. Okay, so the boy lived happily ever after… Now onto the technical stuff that you were expecting to read.
AnalysisTo better illustrate the productivity gains brought by precompilation, we’ll use an experiment that will run 10 times with 9 randomly selected projects out of all the projects existing in Hootsuite. Out of the 10 tests, the average of last 5 results will be used for comparison of efficiency. The purpose of choosing the last 5 projects will be to avoid discrepancies caused by file system caching. In each tests, each project will be precompiled separately in separate tests but in the same manner to validate the efficiency of precompilation. However, they will be compiled in order of their project size. The below shows the results observed.
Figure 1. Absolute time observed when bundling with different number of Precompiled Projects.We run the first test by enabling precompilation for different numbers of projects, resulting in Figure 1. As the graph portrays, the time for the entire project to bundle decreases as the number of precompiled projects increases. Through a simple calculation, we observe that we were able to save up to roughly 40.11% of the time required to bundle the entire project.
Figure 2. Accumulation of time saved with different number of precompiled projects
Figure 2 shows the amount of time saved while bundling when different number of projects have been precompiled. Ultimately, with all 9 participating projects precompiled, each developer would be saving roughly 54 seconds per bundling. Assuming 100 developers must bundle their project once a day, we would see 54 seconds x 100 = 1.5 hours freed. This means we will gain an additional 33 hours of productivity in terms of time efficiency within a month (22 business days). Precompilation salvaged a bit less than a week worth of a single programmer’s time per month! This is amazing
Figure 3. Amount of time freed per each precompiled project.
Figure 3 shows the time freed for each individual project strictly relative to the number of ES6 files in each projects. The graph above illustrates that time saved is not exponential, as other graphs have visually suggested, but linearly proportional to the number of files that need to be compiled. This strongly suggests that as more files are precompiled, more time would be saved, in a linear fashion.
Mind-blowing! It seems after analysis of our experiment that integrating this precompilation feature is a must. But as a project lead, one should not simply integrate Babel Precompilation into their project blindly. For instance, if the project is a big monolith, there is no point of pre-compiling since any changes in the code would result in compiling all the code again. In other cases where there are only a small number of associated projects, the users may not be able to practically tell the difference or benefit from time saved. However, if bundling time takes more than the time for your coffee machine to spit out a cup of fresh coffee, I strongly recommend researching what Babel Precompilation can do for you and your team.