Reference count issue

[SUSYUSTC]

I expected that numexpr.evaluate(xxx, out=array) should write data to array, and eventually it like a fast version of array[:] = xxx, so it should not change the reference count. However, in the following case I expect that del B in the second case should decrease the reference count by 1, but it's not changed. Why does it happen and how to fix it?

import sys
import numpy as np
import numexpr

A = np.zeros(10000)
B = A.reshape((100, 100))
B[:] = 1
print(sys.getrefcount(A), np.sum(A))
del B
print(sys.getrefcount(A), np.sum(A))

r = np.random.random((100, 100))
A = np.zeros(10000)
B = A.reshape((100, 100))
numexpr.evaluate("r + 1", local_dict={'r': r}, global_dict={}, out=B)
print(sys.getrefcount(A), np.sum(A))
del B
print(sys.getrefcount(A), np.sum(A))

The output is

3 10000.0
2 10000.0
3 14951.218372702608
3 14951.218372702608

versions:
numexpr: 2.11.0
numpy: 2.2.0
python: 3.11

[27rabbitlt]

Looking into this. Seems similar to issue 310?

…

On Wed, 20 Aug 2025 at 07:21, Jiace Sun ***@***.***> wrote: *SUSYUSTC* created an issue (pydata/numexpr#521) <#521> I expected that numexpr.evaluate(xxx, out=array) should write data to array, and eventually it like a fast version of array[:] = xxx, so it should not change the reference count. However, in the following case I expect that del B in the second case should decrease the reference count by 1, but it's not changed. Why does it happen and how to fix it? import sys import numpy as np import numexpr A = np.zeros(10000) B = A.reshape((100, 100)) B[:] = 1 print(sys.getrefcount(A), np.sum(A)) del B print(sys.getrefcount(A), np.sum(A)) r = np.random.random((100, 100)) A = np.zeros(10000) B = A.reshape((100, 100)) numexpr.evaluate("r + 1", local_dict={'r': r}, global_dict={}, out=B) print(sys.getrefcount(A), np.sum(A)) del B print(sys.getrefcount(A), np.sum(A)) The output is 3 10000.0 2 10000.0 3 14951.218372702608 3 14951.218372702608 — Reply to this email directly, view it on GitHub <#521>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A33BDH3XSSQNSFHK6G4LOID3OQATXAVCNFSM6AAAAACEKJLA76VHI2DSMVQWIX3LMV43ASLTON2WKOZTGMZTMNRQGQ2TANA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[27rabbitlt]

Interestingly, if we change the B = A.reshape to B = A, we get:

import sys
import numpy as np
import numexpr

A = np.zeros(10000)
B = A.reshape((100, 100))
B[:] = 1
print(sys.getrefcount(A), np.sum(A))
del B
print(sys.getrefcount(A), np.sum(A))

r = np.random.random((100, 100))
A = np.zeros((100, 100))
# B = A.reshape((100, 100))
B = A
numexpr.evaluate("r + 1", local_dict={'r': r}, global_dict={}, out=B)
print(sys.getrefcount(A), np.sum(A))
del B
print(sys.getrefcount(A), np.sum(A))

3 10000.0
2 10000.0
4 15007.813492629304
3 15007.813492629304

So here refcount of A becomes 4 before deleting B, which is already wrong..

[SUSYUSTC]

I realize that it's actually because of the cache behavior of numexpr. It can be solved with some empty evaluation numexpr.evaluate('0'). However, I don't quite understand why this cache behavior exists. Is there a way to globally disable it?

For this code now it's fine:

import sys
import numpy as np
import numexpr

A = np.zeros(10000)
B = A.reshape((100, 100))
B[:] = 1
print(sys.getrefcount(A), np.sum(A))
del B
print(sys.getrefcount(A), np.sum(A))

r = np.random.random((100, 100))
A = np.zeros(10000)
B = A.reshape((100, 100))
numexpr.evaluate("r + 1", local_dict={'r': r}, global_dict={}, out=B)
numexpr.evaluate("0")
print(sys.getrefcount(A), np.sum(A))
del B
print(sys.getrefcount(A), np.sum(A))

Output:

3 10000.0
2 10000.0
3 15037.130247516325
2 15037.130247516325

Regarding why B = A is different, it might be related to how does the cache work exactly in numexpr, maybe the cache is somehow sharing the same reference with the variable outside in some cases?

[27rabbitlt]

I realize that it's actually because of the cache behavior of numexpr. It can be solved with some empty evaluation numexpr.evaluate('0'). However, I don't quite understand why this cache behavior exists. Is there a way to globally disable it?

Good point. numexpr does store a cache for compiled expression. So for example if you previously called evaluate("...") and you can then directly call re_evaluate() to run the last expression. In this way numexpr will not need to recompile the expression into AST and stuff.

I will look further into this and see why when B=A case it behaves differently.

Is there a way to globally disable it

No I don't think so, unfortunately

[SUSYUSTC]

May I ask why this cache behavior is kept? It's pretty annoying at least for me. Is it served for some reason, or just difficult to remove?

[FrancescAlted]

The cache is very important when you repeatedly call re_evaluate() to accelerate computations, and several packages are using this feature. Making the cache optional is a possibility, although fixing the reference count seems best. We would gladly accept PRs on this.

[27rabbitlt]

The cache is very important when you repeatedly call re_evaluate() to accelerate computations, and several packages are using this feature. Making the cache optional is a possibility, although fixing the reference count seems best. We would gladly accept PRs on this.

Here what would be the expected behavior?

It seems that cache should increase the reference so the bug here is that

A = np.zeros((100, 100))
# B = A.reshape((100, 100))
B = A
numexpr.evaluate("r + 1", local_dict={'r': r}, global_dict={}, out=B)
print(sys.getrefcount(A), np.sum(A))

The output should be 3 instead of 4.

This bug is different from what this issue is trying to track so probably I can create a new issue and try to fix it. What do you think @FrancescAlted

[FrancescAlted]

@27rabbitlt I think you are right, and that refcount should be 3. If you can fix this, chances are that we would be approaching a solution for this issue too.

[27rabbitlt]

@27rabbitlt I think you are right, and that refcount should be 3. If you can fix this, chances are that we would be approaching a solution for this issue too.

Start looking into this. Never touched C code of numexpr but this could be a good oppourtunity ;)

[27rabbitlt]

After some experiment, it seems that the problem is not about numexpr.

When we try:

import numpy as np
import sys

A = np.arange(100)
B = A
out = B
print("real number of ref of A before del B: ", sys.getrefcount(A) - 1)
del B
print("real number of ref of A after del B: ", sys.getrefcount(A) - 1)
del out
print("real number of ref of A after del out: ", sys.getrefcount(A) - 1)
print('===========')

A1 = np.arange(100)
B1 = A1.reshape((10, 10))
print("real number of ref of A1 before del B1: ", sys.getrefcount(A1) - 1)
del B1
print("real number of ref of A1 before del B1: ", sys.getrefcount(A1) - 1)
print('===========')

A2 = np.arange(100)
B2 = A2.reshape((10, 10))
out2 = B2
print("real number of ref of A2 before del B2: ", sys.getrefcount(A2) - 1)
print("real number of ref of B2 before del B2: ", sys.getrefcount(B2) - 1)
print("real number of ref of out2 before del B2: ", sys.getrefcount(out2) - 1)
del B2
print("real number of ref of A2 after del B2: ", sys.getrefcount(A2) - 1)
print("real number of ref of out2 after del B2: ", sys.getrefcount(out2) - 1)
del out2
print("real number of ref of A2 after del out2: ", sys.getrefcount(A2) - 1)
print('===========')

A3 = np.arange(100)
B3 = A3.reshape((10, 10))
out3 = B3
print("real number of ref of A3 before del out3: ", sys.getrefcount(A3) - 1)
del out3
print("real number of ref of A3 after del out3: ", sys.getrefcount(A3) - 1)
del B3
print("real number of ref of A3 after further del B3: ", sys.getrefcount(A3) - 1)

The output is:

❯ python test_reshape.py
real number of ref of A before del B:  3
real number of ref of A after del B:  2
real number of ref of A after del out:  1
===========
real number of ref of A1 before del B1:  2
real number of ref of A1 before del B1:  1
===========
real number of ref of A2 before del B2:  2
real number of ref of B2 before del B2:  2
real number of ref of out2 before del B2:  2
real number of ref of A2 after del B2:  2
real number of ref of out2 after del B2:  1
real number of ref of A2 after del out2:  1
===========
real number of ref of A3 before del out3:  2
real number of ref of A3 after del out3:  2
real number of ref of A3 after del B3:  1

In this example we can see that in the A2, B2 stuff:

• We create variable out, refcount of A2 doesn't change;
• We del B2, refcount of A2 doesn't change either.
• We del out2, refcount of A2 decrease

It seems that the B2's ref of A2 (created by reshape) is stolen by this assignment out = B2. In A3 , B3 case we deleteout first and it seems that the ref in out is returned back to B. I'm not sure if this is intended behavior.

This is related to this issue in this way:

In the example provided by OP we have

r = np.random.random((100, 100))
A = np.zeros(10000)
B = A.reshape((100, 100))

Here B will be the out parameter of ne.evaluate(). So the ref in B will be stolen by out. Then in numexpr/necompiler.py:932, we assign out in a dict kwargs. Later this kwargs is further iterated in numexpr/utils.py:246:

  for k, v in kwargs.items():
      data[k] = v

Here v is the out parameter and data will be persisted to _numexpr_last.l, which is our context-aware cache dictionary. So eventually the variable B, created by reshape, is stolen by that cache dictionary. Thus deleting B makes no difference in refcount of A. And if we comment out the data[k] = v line, deleting B will decrease the refcount of A by 1.

So in summary, it seems that numexpr can do nothing about this. What do you think @FrancescAlted ?

[FrancescAlted]

Good detective work @27rabbitlt ! I agree with your analysis. A possibility is to add a new parameter for evaluate() (say disable_cache=False) that, if turned True, it disables all the cache logic completely. This should be totally backward compatible, and if somebody enables it, she should know that she won't be able to use the caches (essentially, re_evaluate() will raise an Error). What do you think?

[27rabbitlt]

Good detective work @27rabbitlt ! I agree with your analysis. A possibility is to add a new parameter for evaluate() (say disable_cache=False) that, if turned True, it disables all the cache logic completely. This should be totally backward compatible, and if somebody enables it, she should know that she won't be able to use the caches (essentially, re_evaluate() will raise an Error). What do you think?

This sounds very reasonable. I will open a PR for this later.

btw I also created a thread in numpy's mailing list since this seems to be a problem on their side. The refcount is stolen doesn't sound like a normal behavior

[27rabbitlt]

Thanks for the answer from numpy mailing list: https://mail.python.org/archives/list/numpy-discussion@python.org/thread/ASBA4K26XPLTYG2Z3LT3ARHIQC6H4FUD/

In conclusion, B = A.reshape will make B.base() to hold a reference of A. So increasing the reference of B by out = B will not increase the reference of A. Also, only when all references of B vanishes, the reference of A would decrease 1. So together with our cache machenism, this explains every phenomena discussed in this issue. None of the proposed phenomena is a bug.

But still, I will create a PR to add a new parameter for evaluate to support disable_cache.

[FrancescAlted]

PR #546 adds the disable_cache param. Closing this, as we cannot do much else.