# 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:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\
**Post date:** [July 22, 2025, 7:15am UTC](https://fortran-lang.discourse.group/t/excessive-main-memory-usage-by-stdlib-hashmaps-routines/9924/10 "2025-07-22T07:15:57Z")

</div>

> [@Chuckyvt](#):
>
> The key is an int\_16 allocatable array wrapped in a derived type. This could almost certainly be changed to native allocatable int\_16 array. Could also consider changing the int\_16 allocatable array to a pointer.

I don’t think it would change anything. The memory overhead is not because of the derived type encapsulation, but because of the internal descriptor that comes with a pointer or allocatable array. From what I can see, the descriptor of a 1D array is 64 bytes large with gfortran, and 72 bytes with ifx.

Using a `type(c_ptr)` would reduce the memory footprint to 8 bytes, but the code would be more complex and probably less efficient (with many calls to `c_loc()` and `c_f_pointer()`. Alternatively, the whole hashmap library could be written in C, with wrapper routines for Fortran.

PS: the estimations by Grok look fairly wrong

Edit: the whole `chaining_map_entry_type` storage size is 112 bytes in gfortran / 224 bytes in ifx.  
hash\_val: 8 / 8  
key: 64 / 72  
other: 24 / 128  
inmap: 8 / 8  
next: 8 / 8

---

_[View the full topic](https://fortran-lang.discourse.group/t/excessive-main-memory-usage-by-stdlib-hashmaps-routines/9924)._