Eleventy 3.0.0 export performance regression #3473
Comments
j9t
changed the title
|
I'm currently migrating Eleventy Notes from v2.0.1 to v3. The template has just 45 files but the build time increases from ~0.35s to ~0.64s. That's still pretty fast of course, but I didn't expect that the build time increases with the update. Edit: I now tested Eleventy in a new project without any config on 10k markdown files and v3 is ~1s slower than v2. |
|
We're processing approximately 5,000 files. On 11ty 2.0.1, it took 72.95 seconds (14.7ms per file), but on 11ty 3.0.0, it takes 186.98 seconds (37.5ms per file), nearly tripling the build time. I plan to start a fresh project to investigate further and determine what is impacting performance. |
|
Could you also log Performance Metrics? That could help understand the specific part being slower. |
|
Won't add the full log (~16,000 lines), but here is the ones that seem to use alot of resources. The debug took 110.76 seconds (22.2ms each) |
|
Thanks! Looks I/O bound (Template Read and Write) |
|
Attaching my own log. A bit faster on this run (55 seconds), but slower than pre-Eleventy 3.0.0. |
|
Thanks. I spotted: Unrelated (see |
|
I stripped everything from my project, leaving only the markdown files. I also created empty shortcodes to avoid refactoring them. Below is a comparison between 11ty 2.0.1 and 3.0.0 for generating files from markdown, both using the same stripped-down code with the debug variable.
The results below are from five builds. The first build needed to generate the output folder.
|
Side note, I took this to investigate and noticed I don’t need (That’s not to distract from the issue though—Eleventy performance did degrade after the upgrade.) |
|
Spent a little time on this one in PR #3493 Bench results: Worth nothing that there is extra overhead that came with ESM support and the ESM loader built into Node.js that is just a bit slower overall, unfortunately—but improvements are being made! |
|
For other folks, it’d be very helpful to get a I will also accept these via email if you don’t want to attach them to the issue: |
|
Hey @zachleat, Thanks for your time on this one! Your command didn't work on my side, but using this one works It has generated 2 files: |
|
Hey @michael-proulx your profiles revealed the same slowdowns eliminated in #3493! Thank you for uploading! Looks like you’ll save about 1.8s on your build with those improvements 
|
|
I also face a big increase of my build time with Eleventy 3 (but it's not the only change in my project, and issues with time limit on Netlify: https://mamot.fr/@nhoizey/113378722980419766 I ran the command to get the I guess I should use
|
|
I have a strange issue where locally on my MacBook Pro (M1), it builds my blog in ~9s, but on my VPS, it starts fast, but then slows down to a halt the more pages it writes, until eventually it gets killed.
If I run |
|
Server: Client: One thing sticks out in the server debug logs:
Why would passthrough copying take so long? |
|
Some more profiles, in case they're useful: |
|
@nhoizey is your Eleventy v3 project checked in somewhere? I don’t see it on GitHub https://github.com/nhoizey/nicolas-hoizey.com/branches/all |
@tomayac passthrough copy currently happens in parallel with the rest of the Eleventy build and the debug times are total time (not “self” time). Here’s the code in the upstream dep we’re using: https://github.com/11ty/recursive-copy/blob/b8a108dd0e80dd5043042fd4047458f6ffb46b81/lib/copy.js#L330-L375 I’m curious how a move away from streams internally might change build times. Related: #3360 Also related, the new |
|
@gerwitz looks like your project is making heavy use of https://www.npmjs.com/package/d3-selection which is taking the bulk of your build time! If you provide the code to |
My My |
|
Thanks, @zachleat! In case anyone can make sense of this, I've recorded a video that compares a local build ( eleventy.mp4The server is a Ionos VPS with 2 CPU cores and 2GB of RAM. Nothing fancy, but also nothing super underpowered I think.
There's nothing else running on the server apart from WordPress. Does anyone have an idea what could be going on? |
You can find that (and I'm not looking for remediation! Only sharing my profile in case you find it helpful. LMK if you'd like me to try profiling a 2.x build for comparison. |
|
@tomayac I’d start by futzing with the Image plugin concurrency—it defaults to 20 now but it seems like you might want to decrease it. https://www.11ty.dev/docs/plugins/image/#change-global-plugin-concurrency I think we’ll probably swap to use something better in the next major (which is next in my work rotation, so coming soon): 11ty/eleventy-img#258 Notably, v3.0.1 of core is going to introduce a concurrency option for rendering, follow along here: #3585 |
Sorry if this is obvious for someone else, but it's not for me. How would I change the concurrency if I use the plugin as follows? eleventyConfig.addPlugin(eleventyImageTransformPlugin, {
// concurrency: 4, // 👈 This is what I tried, but it didn't have an impact.
transformOnRequest: false,
extensions: 'html',
// The image formats to generate, in order of preference
formats: ['avif', 'webp', 'svg', 'auto'],
// The images sizes to generate
widths: [368, 736, 900],
defaultAttributes: {
sizes: 'auto',
loading: 'lazy',
decoding: 'async',
},
}); |
|
@tomayac It’s a global prop on the default export. If you import eleventyImage, { eleventyImageTransformPlugin } from "@11ty/eleventy-img";
eleventyImage.concurrency = 2;
export default function(eleventyConfig) {
eleventyConfig.addPlugin(eleventyImageTransformPlugin, {
// … |
and others
Operating system
macOS 14.6.1
Eleventy
3.0.0
Describe the bug
Just kicking this off as an observation, I’m consistently observing a significant performance regression after upgrading from Eleventy 2.0.1 to 3.0.0.
With no other changes, processing ~10,000 files resulting in ~1,500 output files took ~45 seconds before, and ~65 seconds now.
I can make access to the private repo available if of interest, but do also submit this to give other Eleventy users a chance to collect similar observations, as well as to comment if this is a known issue or perhaps being worked on.
Reproduction steps
(As described.)
Expected behavior
Given how important performance is, export time stays roughly the same or improves.
Reproduction URL
No response
Screenshots
No response
The text was updated successfully, but these errors were encountered: