Elmstatic v0.7.0 has substantially improved performance as it generates HTML pages in parallel.
However, Node provides also the ability to run computations in worker threads, and that’s useful for running CPU-intensive work in parallel. Generating pages happens to be very amenable to be done in parallel, as each page is generated independently, so I decided to take advantage of that.
It wouldn’t make sense to create a thread per page. Instead, it would be good to have a pool of worker threads, with its size determined by the number of CPU cores.
Luckily, there’s an NPM package that does just that,
workerpool. It also conveniently allows me to pass a function to execute in a thread.
With this package, I need to create a thread pool, and then I can simply pass it a function and some arguments, and get a
const workerPool = WorkerPool.pool() workerPool.exec(generateHtml, [elmJs, page]) .then((html) => /* write HTML to disk etc. */)
The function passed to the pool has to be serialisable.
Once the work is done, the pool needs to be terminated with
Overall, the changes turned out to be minimal, although of course promises have made the code a bit more convoluted. But on the plus side, Elmstatic now generates sites quite a bit faster.
My book, Practical Elm for a Busy Developer, skips the basics and gets right into explaining how to do practical stuff. Things like building out the UI, communicating with servers, parsing JSON, structuring the application as it grows, testing, and so on. No handholding — the focus is on giving you more substance.
It’s up to date with Elm 0.19.
Pop in your email to get a sample chapter.
(You will also get notifications of new posts along with other mailing list only freebies.)