4

I have an array which is used to track various values. The array is 2500x1700 in size, so it is not very large. At the end of a session I need to reset all of the values within that array back to zero. I tried both creating a new array of zeros and replacing all values in the array with zeros and creating a brand new array is much faster.

Code Example:

for _ in sessions:
    # Reset our array
    tracking_array[:,:] = 0

1.44 s ± 19.1 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

Versus

for _ in sessions:
    # Reset our array
    tracking_array = np.zeros(shape=(2500, 1700))

7.26 ms ± 133 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

Why is creating an entirely new array so much faster when compared to just replacing the values in the array?

Jérôme Richard
  • 41,678
  • 6
  • 29
  • 59
Juscallmesteve
  • 147
  • 8
  • 1
    There's a C function for zeroing out a region of memory. It's very, _very_ cheap when you're using a codepath that can use it. And there's also a single standard-library C function for allocating a block of memory and getting it zeroed at that time. – Charles Duffy Apr 26 '21 at 17:11
  • Wheras `tracking_array[:,:] = 0` needs to be able to handle non-zero values too, so it can't take that optimized path. – Charles Duffy Apr 26 '21 at 17:11
  • Well that would explain it. Thank you – Juscallmesteve Apr 26 '21 at 17:15

1 Answers1

6

The reason is that the array is not filled in memory on mainstream operating systems (Windows, Linux and MaxOS). Numpy allocates a zero-filled array by requesting to the operating systems (OS) a zero-filled area in virtual memory. This area is not directly mapping in physical RAM. The mapping and zero-initialization is generally done lazily by the OS when you read/write the pages in virtual memory. This cost is paid when you set later the array to 1 for example. Here is a proof:

In [19]: %timeit res = np.zeros(shape=(2500, 1700))
10.8 µs ± 118 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

In [20]: %timeit res = np.ones(shape=(2500, 1700))
7.54 ms ± 151 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

The former would imply a RAM throughput of at least 4.2 GiB/s which is not high but fair. The latter would imply a RAM throughput of at least roughly 2930 GiB/s which is stupidly high since my machine (as well as any standard desktop/server machine) is barely able to reach 36 GiB/s (using a carefully-optimized benchmark).

Jérôme Richard
  • 41,678
  • 6
  • 29
  • 59