Is there a way to get the underlying memory array size of a tensor?

Fei_Liu: <p>E.g. I have this code snippet</p>
<pre><code class="lang-python">x = torch.rand(1000, 1000)  # this will allocate a memory block of 4M in bytes
x1 = x[0:1]  # only selecting the first row. x1 itself contains only 1K floats, but for now it shares the underlying memory array with x
torch.save(x1, 'some/disk/file')  # after this, `some/disk/file` will be of size roughly 4M instead of 4K.
</code></pre>
<p>Hence the need: I want to avoid this extra space waste with some smart size checks before disk save (instead of calling <code>.clone().contiguous()</code> every time). Is there a way to do it? The usual <code>.numel()</code> etc. doesn’t suits this use case.</p>

Fei_Liu: <p>Or even better, are there any “somewhat low level” torch APIs to tell some information about the underlying memory array, e.g. whether two tensors are sharing the same memory array, and the size of the memory array.</p>

KFrank: <p>Hi Fei!</p>
<aside class="quote no-group" data-username="Fei_Liu" data-post="2" data-topic="182626" data-full="true">
<div class="title">
<div class="quote-controls"></div>
<img loading="lazy" alt="" width="24" height="24" src="https://discuss.pytorch.org/user_avatar/discuss.pytorch.org/fei_liu/48/36219_2.png" class="avatar"> Fei_Liu:</div>
<blockquote>
<p>are there any “somewhat low level” torch APIs to tell some information about the underlying memory array, e.g. whether two tensors are sharing the same memory array, and the size of the memory array.</p>
</blockquote>
</aside>
<p>Try <code>some_tensor.untyped_storage()</code> and <code>some_tensor.data_ptr()</code>.</p>
<p>Best.</p>
<p>K. Frank</p>

Fei_Liu: <p>This is exactly what I’m looking for. Thank you!</p>

Fei_Liu: <p>I found a new tricky case:<br>
If I construct a torch tensor by calling <code>from_numpy</code> on an np.ndarray slice, the tensor will hold the full shared memory of the np.array object but <code>.untyped_storage().nbytes()</code> only reveals the tensor’s occupied size (instead of the full shared size). The program will continue to cost the full underlying memory block even if the original ndarray is deallocated. See this code snippet as an example:</p>
<pre><code class="lang-auto">import time
import gc
import numpy as np
import torch

# Create an np.ndarray taking 8GB mem, then only use the first-element slice to construct the tensor
x = torch.from_numpy(np.ones(2 ** 30)[:1])

# At this stage the giant array (temp variable) goes out of scope. We call gc.collect() to make sure it's erased.
gc.collect()

print(x.untyped_storage().nbytes())  # output: 8

# However, top still shows that the program takes ~8GB mem. I paused the program and looked at the `top` results for 10 seconds to make sure ^_^!
time.sleep(10)
</code></pre>
<p>I’m pretty sure this is not related to garbage collection (<code>gc</code> is doing its work), since I tested it with various scenarios (e.g. a: only creating the large ndarray variable and see if mem size reduces after gc, or b: delete both the ndarray and the tensor and then gc). Results show that it indeed is the torch.tensor holding the large 8GB memory chunk (which is not revealed by its <code>.untyped_storage().nbytes()</code> ). Is there a way to identify such cases?</p>