# RAM needed to initialise large matrices

**URL:** <https://discourse.julialang.org/t/ram-needed-to-initialise-large-matrices/78302>\
**Category:** General Usage\
**Tags:** memory, memory-allocation\
**Created:** [March 22, 2022, 8:04pm UTC](https://discourse.julialang.org/t/ram-needed-to-initialise-large-matrices/78302 "2022-03-22T20:04:12Z")\
**Posts on this page:** 1\
**Showing post:** 30

<div class="post-metadata">

**Author:** ![Sukera](https://avatars.discourse-cdn.com/v4/letter/s/ce7236/32.png) [@Sukera](https://discourse.julialang.org/u/Sukera)\
**Post date:** [March 23, 2022, 8:29am UTC](https://discourse.julialang.org/t/ram-needed-to-initialise-large-matrices/78302/30 "2022-03-23T08:29:08Z")

</div>

> [@c42f](#):
>
> (Edit: As a side note - it seems technically possible to do lazy zero fill in (a) the case that a large array happens to be allocated with [`mmap` and `MAP_ANONYMOUS`](https://man7.org/linux/man-pages/man2/mmap.2.html) somewhere deep in the allocator and (b) `zero(eltype(a))` happens to be a bits type with a bit pattern of zeros. I think this would only help in specialized circumstances, though.)

For a detailed discussion on the challenges that would crop up almost immediately when trying this, check out [Faster zeros with calloc](https://discourse.julialang.org/t/faster-zeros-with-calloc/69860). The TL;DR is that the cost of initialization doesn’t vanish but gets shifted to the first write instead and that growing such an array immediately looses the “zero initialized” property.

---

_[View the full topic](https://discourse.julialang.org/t/ram-needed-to-initialise-large-matrices/78302)._