BUG: Factor out slow getenv call used for memory policy warning
#24248
Conversation
Using `getenv` regularly is probably not great anyway, but it seems very slow on windows which leads to a large overhead for every array deallocation here. Refactor it out to only check on first import and add helper because the tests are set up slightly differently. (Manually checked that the startup works, tests run with policy set to 1, not modifying it and passing.)
|
LGTM. I am trying to run the benchmark comparison on this, but something seems off It would be nice to see that this has some echo in the benchmarks. |
|
Hmmm, good question, I do think a few of our benchmarks should notice this, although I don't think we have dealloc benchmarks specifically. works for me on main on MacOS, but I don't have access to my windows test machine on which I dug into this right now. (scalar, because I suspect a few of them create temporary 0-D arrays making up a big chunk of their overhead. Another benchmark to try could be I cannot see a performance difference on MacOS. I suspect the only reason why this |
|
Once I worked out that I had pkg-config set up to use OpenBLAS on windows, which does not work (see #24251), I could disable it and run benchmarks. It seems benchmarks for For this PR Looks good! |
|
Thanks @seberg |
Using
getenvregularly is probably not great anyway, but it seems very slow on windows which leads to a large overhead for every array deallocation here.Refactor it out to only check on first import and add helper because the tests are set up slightly differently.
(Manually checked that the startup works, tests run with policy set to 1, not modifying it and passing.)
Closes gh-24232.