# Excessive main memory usage by stdlib\_hashmaps routines

**URL:** <https://fortran-lang.discourse.group/t/excessive-main-memory-usage-by-stdlib-hashmaps-routines/9924>\
**Category:** stdlib\
**Created:** [July 15, 2025, 6:40am UTC](https://fortran-lang.discourse.group/t/excessive-main-memory-usage-by-stdlib-hashmaps-routines/9924 "2025-07-15T06:40:57Z")\
**Posts on this page:** 3\
**Page:** 2

<div class="post-metadata">

**Author:** ![jwmwalrus](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jwmwalrus/32/4483_2.png) [@jwmwalrus](https://fortran-lang.discourse.group/u/jwmwalrus)\
**Post date:** [July 23, 2025, 2:46pm UTC](https://fortran-lang.discourse.group/t/excessive-main-memory-usage-by-stdlib-hashmaps-routines/9924/22 "2025-07-23T14:46:07Z")

</div>

If going for a custom hashmap implementation is an option, maybe a swiss table could be useful here.

(Disclaimer: For Go 1.24, its native map implementation went from chaining map to swiss table, so I asked Gemini to generate an equivalent in C, and even though it hallucinated things like `uint66_t`, it’s quite straightforward.)

If what needs to be stored is only key and value of `int32` type, then the memory usage reduces to

```fortran
type :: slot_t
    integer(INT32) :: key, val
end type

type :: group_t
    integer(INT8) :: ctrl(8) ! stores only the rightmost 7 bits of the hash
    type(slot_t) :: slots(8)
end type

type :: map_t
    integer :: resident = 0, deleted = 0, ngroups = 2, capacity = 16
    integer :: grow_threshold, shrink_threshold, compact_threshold
    type(group_t), allocatable :: groups(:)
end type

```

So that’s **9 bytes** per slot —plus some compiler-specific overhead?

Since there are no linked lists, recursion is out of the question, along with stack exhaustion. The heart of the swiss table implementation is in its [`find_slot` algorithm](https://github.com/dolthub/swiss/blob/9ab8df34488d97ac1f38491ea19c10f39d3dcb14/map.go#L269), so that’s the only thing in need of careful consideration.

The implementation in Go 1.24’s standard library is more complex than the one in the link above, since it relies on the runtime for AES- and SSE-related instructions.

---

<div class="post-metadata">

**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\
**Post date:** [July 23, 2025, 4:46pm UTC](https://fortran-lang.discourse.group/t/excessive-main-memory-usage-by-stdlib-hashmaps-routines/9924/23 "2025-07-23T16:46:56Z")

</div>

I’ve put a simple test [here](https://godbolt.org/z/PKWsWao7T) that shows total storage _actually_ used by compilers. Indeed it looks like gfortran is using the least memory, while flang uses the least for the 1D allocatable descriptor:

| Compiler | Bytes (total) | Bytes (key only) | Bytes (`class(*)`) |
| --- | --- | --- | --- |
| nvfortran | 312 | 152 | 136 |
| flang | 144 | 48 | 40 |
| gfortran | 112 | 64 | 24 |
| ifx | 224 | 72 | 128 |

---

<div class="post-metadata">

**Author:** ![Chuckyvt](https://avatars.discourse-cdn.com/v4/letter/c/53a042/32.png) [@Chuckyvt](https://fortran-lang.discourse.group/u/Chuckyvt)\
**Post date:** [July 23, 2025, 5:21pm UTC](https://fortran-lang.discourse.group/t/excessive-main-memory-usage-by-stdlib-hashmaps-routines/9924/24 "2025-07-23T17:21:46Z")

</div>

Thanks! Note the stdlib hashmap currently uses 32 bit hashing, so int\_hash and int\_index are int32 in the current stdlib. However changing those values didn’t make any changes when I ran it.

[Previous page](https://fortran-lang.discourse.group/t/excessive-main-memory-usage-by-stdlib-hashmaps-routines/9924.md?page=1)