-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Assess build performance #85
Comments
@ctrueden this isn't essential but I'm interested in your thoughts |
Also this is largely a Windows problem. Even my infinitely-better desktop takes 359.18 seconds to build. But my Ubuntu 20.04 subsystem on the same computer builds in 114 seconds. Supposedly wdm should normalize build times between systems but it hasn't had any effect in my experience. |
I don't have much insight, other than a naive claim that "Ruby is slow" and "Windows file locking is slow", and perhaps more wackily: "GraalVM's implementation of Ruby is 8x faster." I wonder if it's possible to run Jekyll using GraalVM?? 😜 |
@hinerm Are you OK closing this issue, now that we are building locally with Jekyll 4.2? |
A fresh build of the site seems quite slow on my laptop (10+ minutes) and even rebuilds with
--incremental
can be slow.The general profile is:
The heavy use of includes, particularly in the main menu, are the primary bottleneck. Jekyll 4 has a built-in include caching mechanism, but is incompatible with the gh-pages gem. I tried using the third-party include cache but it has some restrictions on how includes are called and so without any modifications to our templates it actually increased build time to 769.185 seconds.
Other common suggestions for improving performance are switching to c-compiled gems, particularly
liquidc
andsassc
. I triedliquidc
thinking it might improve performance of the include parsing.. but it actually slowed things down to 994.955 seconds...!!In any case, the include performance is probably disk I/O bound. When parsing
include
templates, liquid reads the file from disk EACH time. So,main-menu
's extensive use ofincludes
represents the bulk of this time (main-menu
itself is included twice per page: once directly and once in thehamburger-menu
). I tested replacing themain-menu
's includes with direct HTML and it dropped the build time almost an order of magnitude (107.511 seconds).Given that the content is static I think converting to HTML could be reasonable. Open to other thoughts.
The text was updated successfully, but these errors were encountered: