This adds these two fields to a HashMap Entry:
uint32_t hash
uint32_t distance_from_start_index
Compared to master branch, standard library tests compiled 8.4% faster
and took negligible (0.001%) more memory to complete. The amount of
memory used is still down from before 8b82c4010480 which moved indexes
to be stored separately from entries.
So, it turns out, keeping robin hood hashing plus separating indexes
did result in a performance improvement. What happened previously is
that the gains from separating indexes balanced out the losses from
removing robin hood hashing, resulting in a wash.
This also serves as an inspiration for adding a benchmark to
std.AutoHashMap and improving the implementation.
- split util_base.hpp from util.hpp
- new namespaces: `mem` and `heap`
- new `mem::Allocator` interface
- new `heap::CAllocator` impl with global `heap::c_allocator`
- new `heap::ArenaAllocator` impl
- new `mem::TypeInfo` extracts names without RTTI
- name extraction is enabled w/ ZIG_ENABLE_MEM_PROFILE=1
- new `mem::List` takes explicit `Allocator&` parameter
- new `mem::HashMap` takes explicit `Allocator&` parameter
- add Codegen.pass1_arena and use for all `ZigValue` allocs
- deinit Codegen.pass1_arena early in `zig_llvm_emit_output()`
Total bytes used in stage1 std lib tests:
3.418 -> 3.198 GiB (saving 225 MiB)
There's still this from pass 1 not getting freed:
Const: 6909049 items, 72 bytes each, total 474.407 MiB
This is due to 2 things hanging on to references to IrAnalyze pointers:
* ZigVar->owner_exec->analysis
* LazyValue->ira
The LazyValue one could be solved by memoizing the results after the
lazy value is resolved, and then it could unref the IrAnalyze.
ZigVars that are determined to be comptime const, could have their
const_value set to that value, instead of using the mem_slot_index
mechanism. This would prevent an IrAnalyze ref in some cases.
