Heya people, quick double checking my understanding: The only reason why wasmtime splits type canonicalization into a ModuleTypes and TypeRegistry “phase” is so that a parsed module can be cached on disk and loaded back in a different session right?
or is there some other idk component model requirement for this?
Yes the main motivation for this is AOT compilation (in one form or another). This enables creating a separate artifact from an engine which can later get merged into an engine and loaded at runtime. Nothing to do with components, just the compilation model that we have
yeah, to add a little more color:
ModuleTypes
is all compile-time stuff and is dedupes types within the scope of just a single module or component graphTypeRegistry
is all runtime stuff and dedupes types within the scope of a whole engineit might even make sense to rename these things to like CompileTimeTypes
and RuntimeTypes
or something
aye alright thanks for taking the time :) thats what I figured too :+1:
ive been wondering since Ive seen firefox do just do global type canonicalization but given wasmtime cares more about instantiation time than compilation that checks out
I CAN LEARN WHEN I'M DEAD
wait...
for future reference: there is one more advantage to this two-step process i realized after implementing a half-assed oneshot system yesterday. building up rec groups first and then canonicalizing them through hash consing is much much cleaner than trying to do it all at once
so i went with copying your implementation after all :) we’ll see if that needs tweaking for my needs when I get around to benchmarking
Last updated: Nov 22 2024 at 17:03 UTC