High memory usage during build time in release mode after adopting Elementary

[nicksloan]

I have been porting a fairly complex (but very real-world) set of templates over to elementary, and after only a couple pages, I've seen a massive spike in memory use during build time. I can't share the entire source of my project, but I can describe characteristics of it here to start:

We have three categories of templates: Page, Base, and Component. Page templates are invoked by our Hummingbird controllers. They call a base template and fill various holes. Typically, our base templates have two holes to fill: the page body and head additions. These are @HTMLBuilder properties that are passed in by the page template.

Components are reusable pieces of a page or base template. For example, our base templates use shared components called Head, Header and Footer. The Head component uses a BrandStyles component that outputs some CSS that must be generated per-request.

Our pages use components too. For example, our ClientInvoice page template loads an InvoiceContainer and Payment component. It uses a standard base component as described above. The InvoiceContainer component uses five components: InvoiceHeader, InvoiceMetadata, LineItem, Summary, and Note.

After building out this structure, we saw memory use sky rocket during build time. Prior to introducing Elementary usage was < 5GB during a typical build, and after we see it ballooning to more than 32GB, totally choking our 16 GB Github Actions allocation.

We've so far discovered two things that can substantially improve the memory use, but neither are ideal:

• Replacing direct component invocations with HTMLRaw(SomeComponent().render()). We have found that only doing it to the components in the ClientInvoice template is enough to get things building again. This suggests something about the deeply nested generics is inefficient at build time, and I'm not sure what I can do to improve that.

• Removing our use of Hummingbird-MacroRouting. Though these macros are not used on any of our template types, removing the use of macros at all seems to have improved things substantially, though the builds with Elementary still use a good bit more memory than we were before. I suspect the AST generation when macros are in use is exacerbating a problem with our Elementary code.

Run time performance of Elementary is really great, but the build-time implications are devastating. I'd love to walk through this stuff in more detail with someone who understands Swift build time optimization better than I do. Otherwise, I'm looking for any ideas about patterns to use or avoid.

[sliemeobn]

Thanks for the detailed report!

I am not sure I have much to offer ATM, but I don't think Elementary is using anything out of the ordinary when it comes to compiling swift. At the very least, anyone doing SwiftUI should experiencing the very same behavior (maybe look around in the SwiftUI-how-to-improve-compilation bubble and see what folks are doing over there?)

If nested generics are a problem, maybe try factoring out a few more named sub-components to get shorter type chains (not sure though if that does much, afaik swift is quite ok with these).

Also, I am not quite sure how/why the Hummingbird Macros would be influencing the build times of Elementary stuff - ideally you can try to isolate their effects to see what actually is causing what.

Other than that, I guess one angle of attack would be to get some form of compiler diagnostics/verbose logs and ask on the swift forums what is going on 🤔

[sliemeobn]

maybe another thing you could try @nicksloan :
as part of my performance efforts back then I sprinkled quite a few @inline(__always) on the various _render functions.
that does seem to help for "micro-benchmark" performance, but I was never convinced that it was the right thing to do for "real" projects.

if you find the time, it would be great if you could try compiling your project with these @inline(__always) calls removed and report back what that does to both compile-time and runtime performance.

[nicksloan]

I can check this out this week!

I've been saying the same thing all weekend re: SwiftUI. Really can't fathom how Elementary could be hitting this when I know I've personally been responsible for some much gnarlier SwiftUI trees.

[nicksloan]

See #75 for the output of this discussion.