Concurrent build steps #26
Comments
|
@jimafisk I have been benchmarking
I think by far the best long term approach is incremental builds #130 i.e only building exactly what is absolutely necessary. |
|
Yeah compiling Svelte components is definitely the slowest part, thanks for benchmarking to verify. I used to do this concurrently (8c98790) back when I was executing node scripts. I tried it again later (c2b7b2a) but had some issues so I removed it (8a5693b). I think the performance enhancements you listed are spot on, I'll try to spend some time with that. Incremental builds would be awesome, do you have a sense for how you would approach that? That would make the local dev experience a lot nicer, and I'm all in for anything that can speed up builds. Getting the full build faster will also be important so the feedback loop when running in CI is as quick as possible, but that's more of a prod issue like you said. Good point on not repeating cgo calls. I was mainly focusing on just getting it working initially, but as you pointed out there are places where things are being run multiple times that can be optimized. Ultimately I'd love to avoid cgo altogether, but until someone builds a go-based svelte compiler it's probably something we'll just have to work with. |
|
For incremental builds the simplest might be to store the last modified time or a hash of the content and rebuild anything that violated whichever/maybe both of those. Hashing is reasonably expensive but it could be done concurrently and due to the high cost of compiling it should still be worth it. Generally in production if you are generating static files you won't be changing a large percentage each build so it should be reasonably efficient? The trickiest part is keeping tabs on relationships, what needs to be rebuilt on content changing etc. For local dev we get the actual file names in For anything to work we would need to break the build process out into smaller parts. I have started moving logic into separate functions here. There are a few optimizations also like compiling regex once and using sync.Once here to speed things up a little for local dev by creating some reused logic just once. I am open to any ideas. You have a far better understanding of how everything works. |
Hey @jimafisk I don't have any experience in go or rust. Can I know what issues were you facing with concurrent steps that you mentioned here? |
|
Thanks @s-kris! Are you able to share your benchmarks? I'd love to see them, even if Plenti falls flat a bit :). Concurrency would definitely speed things up, although there are some challenges to doing that with the way we're compiling things in v8. Basically we're loading everything into one giant context, which is not goroutine safe: rogchap/v8go#120 For your local dev, if you're on
That won't happen overnight, but it's something we're thinking about: https://youtu.be/Ql6cZJ-Udkg |
|
Sure :) Here are the benchmarks: (Note: Plenti threw
Same graph without 10k pages data point:
Numbers:
I was reading about your brainstorm discussion on #130. Thanks for the youtube link :) Edit: Some more thoughts here https://twitter.com/_skris/status/1388259901080621056?s=20 |
|
This is super interesting, thanks for sharing @s-kris! I was surprised by the elder/hugo crossover for large sites, might be something for us to look into there. Our bottleneck is probably happening when we render out the HTML fallbacks in V8. Any chance you can share the repo for the benchmark tests so I can debug a bit? Thank you! |
|
Thank you @jimafisk. |
|
Sorry I was clear, do you still have the plenti repo with all the variable number of pages @s-kris? Thanks! |
|
ah! It was nothing custom.
haha! |
|
Tried building with different size sites (e.g. for 1,000 pages:
Error message |
|
I've been playing with different build structures. Historically, I was operating under the assumption that v8 ctx was expensive, so we were creating one global SSRCtx with all SSR components loaded in, and then adding props and generating HTML from it for every page. I've recently tried restructuring so each SSR component gets saved to the virtual filesystem (via afero) during the Client step, then for each content source, creating a new v8 context, loading in those components, then adding props and generating HTML, and once that specific page is complete, closing that specific context: d1ba128 As I expected, this seems to slow down the build in general (I don't have the exact numbers but I think generating 1,000 pages went from like 14 seconds to 43 seconds). However, it did allow me to build larger sites without throwing a timeout error. I was able to build over 5,000 pages without timing out, it just takes a very long time to complete:
I figured I could speed this up some by adding goroutines, and for small sites it seemed to work. One project I'm working on that usually takes 8 seconds with the old build structure, took 10 seconds with the new build structure + goroutines. However, large sites once again started having issues once goroutines were introduced: rogchap/v8go#347 (comment) I probably wouldn't trade slightly slower average size sites (low hundreds of pages) for the ability to complete large site builds (thousands of pages), especially if it takes 10 minutes to do so, which isn't practical for most folks. Maybe there is an option of using v8go for compiling the DOM and SSR components, but using Goja to actually render the template strings to HTML. |
|
Building the client components concurrently (f64a079) seems to have little effect on the overall build: Project 1 results: Consecutive wins ✔️ (5 to 1)
Project 2 results: Consecutive wins ✔️ (4 to 2)
Given these results, I don't intend to convert the architecture in the short term unless we can figure out ways to make improvements. I also tried doing a concurrent HTML build using goja, and although I never quite got it working (wasn't actually producing HTML), it increased the build time for a project I'm working on from about 8 seconds to 35 - 50 seconds. Not sure if Goja can be viable speed-wise unfortunately. |
Build steps:
.jsfiles to build dir/content/layoutbuild.jsscript with NodeJSThese should be broken into goroutines so they run concurrently. If one step relies on a return value from another, we can use channels to block that thread until that data is available. This should speed up build times.
The text was updated successfully, but these errors were encountered: