Caching of compile-time known atoms (from enum literals)

[lambdadog]

This can be considered to be an enhancement of existing functionality, compile-time known atoms really should be cached when used with beam.make. It's not possible to create an atom at compile-time, but it should be possible to cache at least on a thread-and-call-site-local basis by using static locals or the zig equivalent (local struct with var), such as (untested):

const Cache = struct {
  threadlocal var v: ?beam.term = null;
};
if (Cache.v == null) {
  Cache.v = (generate atom);
}
return Cache.v orelse unreachable;

Branch cost is basically made nonexistent by branch predictor, since it's always false except for on the first run on each thread. I haven't checked if beam.term, when an atom, is essentially equivalent to the raw integer id backing the atom, but if it isn't it may be better to store the raw integer id rather than a beam.term value for space efficiency, assuming the NIF interface makes that possible without hacks.

It can be argued that caching atoms is the user's responsibility, but since (aiui) the beam guarantees that atoms are never destroyed this is a cheap optimization that makes beam.make more "free". This could potentially apply to other comptime-known values passed to beam.make as well, at least those that are boxed by the BEAM, though I'm unsure exactly what that would look like re: changes to the implementation and it would probably require either owning the term/creating a GC root/however it works with the NIF interface which I wouldn't want zigler to choose by default (especially since there are no guarantees the beam.make call will ever be reused). Atoms are a special case IMO since they are never GCed and this adds minimal cost even if never reused (which is admittedly a somewhat rare case for the "shape" that NIFs tend to take).

[lambdadog]

If the same compile-time known atom is used at multiple call-sites of beam.make, though, then it would naturally be an optimization to convert it to a term ahead of time and cache that manually, but this seems like a smart choice to me personally, along with that recommendation.