Serdes are slow

[hughsimpson]

Really we shouldn't have any problems decoding and re-encoding the FHIR definitions in like a second, but it takes ages.

[L'Alabameñu]

Glancing over the code base a few things jump out at me:

• subsets require runtime checking. A lot of your subsets are just creating an alias subset Foo of Bar { } is export, but it ends up slowing down potential optimizations. Two ways you could speed up this style of aliasing would be constant Foo = Bar (but now type error messages will complain about Bar, rather than Foo, doesn't seem like that'd be too much of a hassle for you), and class Foo is Bar { }. The constant route is probably a teensy bit faster depending on exactly how MRO happens, but the latter will give you flexibility if you later need to provide deeper introspection on the elements or do more substantial checks on creation.
• In the JSON part, you have two of the biggest performance killers: large given/whens, and mixins. For the former, if you're going to be matching on strings, a way that can vastly improve performance is to use hashes:

    my constant %when = 
        a => { … }, 
        b => { … };

    with %when{$given} { .()         }
    else               { #`[default] }

[hughsimpson]

Yeah the current mixins are an obvious candidate for performance improvements. I don't think the givens are even showing up yet, performance-wise, TBQH. I haven't had the time to revise this really, it was just a little test for some code-generation work that I decided to pretty-up enough to be technically usable, I don't use Raku in my day-to-day and don't know the language awfully well