Hi all-
Thanks for the info re: memory leak. In trying to work around it, I think I’ve
discovered another (still using SuperPack). This leaks ~30MB / run:
hists = zeros((50,64), dtype=int)
for i in range(50):
for j in range(2**13):
hists[i,j%64] += 1
The code leaks using hists[i,j]
On 04.02.2014 18:26, Chris Laumann wrote:
Hi all-
Thanks for the info re: memory leak. In trying to work around it, I
think I’ve discovered another (still using SuperPack). This leaks ~30MB
/ run:
hists = zeros((50,64), dtype=int)
for i in range(50):
for j in range(2**13):
which version of numpy are you using?
there seems to be a leak in the scalar return due to the PyObject_Malloc
usage in git master, but it doesn't affect 1.8.0
On Fri, Jan 31, 2014 at 7:20 AM, Chris Laumann chris.laum...@gmail.comwrote:
Hi all-
The following snippet appears to leak memory
Current scipy superpack for osx so probably pretty close to master. So it's a known leak? Hmm. Maybe I'll have to work on a different machine for a bit.Chris---Sent from my iPhone using Mail Ninja--- Original Message ---which version of numpy are you using?there seems to be a leak in the scalar
On Fri, Jan 31, 2014 at 3:14 PM, Chris Laumann chris.laum...@gmail.com wrote:
Current scipy superpack for osx so probably pretty close to master.
What does numpy.__version__ say?
-n
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
Just to chime in here about the SciPy Superpack... this distribution tracks
the master branch of many projects, and then puts out releases, on the
assumption that master contains pristine code, I guess. I have gone down
strange rabbit holes thinking that a particular bug was fixed already and
the
On Fri, Jan 31, 2014 at 4:29 PM, Benjamin Root ben.r...@ou.edu wrote:
Just to chime in here about the SciPy Superpack... this distribution tracks
the master branch of many projects, and then puts out releases, on the
assumption that master contains pristine code, I guess. I have gone down
On 31.01.2014 18:12, Nathaniel Smith wrote:
On Fri, Jan 31, 2014 at 4:29 PM, Benjamin Root ben.r...@ou.edu wrote:
Just to chime in here about the SciPy Superpack... this distribution tracks
the master branch of many projects, and then puts out releases, on the
assumption that master contains
Hi all-
The following snippet appears to leak memory badly (about 10 MB per execution):
P = randint(0,2,(30,13))
for i in range(50):
print \r, i, /, 50
for ai in ndindex((2,)*13):
j = np.sum(P.dot(ai))
If instead you execute (no np.sum call):
P = randint(0,2,(30,13))
for i in
Hmmm, I see no reason why that would eat up memory. I just tried it out on
my own system (numpy 1.6.1, CentOS 6, python 2.7.1), and had no issues,
Memory usage stayed flat for the 10 seconds it took to go through the
loop. Note, I am not using ATLAS or BLAS, so maybe the issue lies there?
(i
of Numerical Python
Subject: Re: [Numpy-discussion] Memory leak in numpy?
Hmmm, I see no reason why that would eat up memory. I just tried it out on my
own system (numpy 1.6.1, CentOS 6, python 2.7.1), and had no issues, Memory
usage stayed flat for the 10 seconds it took to go through the loop. Note
Subject: Re: [Numpy-discussion] Memory leak in numpy?
Perhaps it is an ESRI/Arcpy issue then. I don't see anything that could be
doing that, though, as it is very minimal.
From:
numpy-discussion-boun...@scipy.orgmailto:numpy-discussion-boun...@scipy.org
[mailto:numpy-discussion-boun
On Wed, Jan 29, 2014 at 7:39 PM, Joseph McGlinchy jmcglin...@esri.com wrote:
Upon further investigation, I do believe it is within the scipy code where
there is a leak. I commented out my call to processBinaryImage(), which is
all scipy code calls, and my memory usage remains flat with
On 29.01.2014 20:44, Nathaniel Smith wrote:
On Wed, Jan 29, 2014 at 7:39 PM, Joseph McGlinchy jmcglin...@esri.com wrote:
Upon further investigation, I do believe it is within the scipy code where
there is a leak. I commented out my call to processBinaryImage(), which is
all scipy code calls,
Subject: Re: [Numpy-discussion] Memory leak in numpy?
On 29.01.2014 20:44, Nathaniel Smith wrote:
On Wed, Jan 29, 2014 at 7:39 PM, Joseph McGlinchy jmcglin...@esri.com wrote:
Upon further investigation, I do believe it is within the scipy code
where there is a leak. I commented out my call
Hi all-
I think I just found a memory leak in numpy, or maybe I just don’t understand
generators. Anyway, the following snippet will quickly eat a ton of RAM:
P = randint(0,2, (20,13))
for i in range(50):
for ai in ndindex((2,)*13):
j = P.dot(ai)
If you replace the last line with
Dear Numpy users,
I have a memory leak in my code. A simple way to reproduce my problem is:
import numpy
class test():
def __init__(self):
pass
def t(self):
temp = numpy.zeros([200,100,100])
A = numpy.zeros([200], dtype = numpy.float)
for i in
Hi Petro,
What version of numpy are you running?
A
On Thu, Jun 13, 2013 at 3:50 PM, Pietro Bonfa' pietro.bo...@fis.unipr.itwrote:
Dear Numpy users,
I have a memory leak in my code. A simple way to reproduce my problem is:
import numpy
class test():
def __init__(self):
The numpy version is 1.7.0
In [5]: numpy.version.full_version
Out[5]: '1.7.0b2'
Thanks,
Pietro
On 06/13/13 16:56, Aron Ahmadia wrote:
Hi Petro,
What version of numpy are you running?
A
On Thu, Jun 13, 2013 at 3:50 PM, Pietro Bonfa'
pietro.bo...@fis.unipr.it
On Thu, Jun 13, 2013 at 8:56 AM, Aron Ahmadia a...@ahmadia.net wrote:
Hi Petro,
What version of numpy are you running?
A
On Thu, Jun 13, 2013 at 3:50 PM, Pietro Bonfa'
pietro.bo...@fis.unipr.itwrote:
Dear Numpy users,
I have a memory leak in my code. A simple way to reproduce my
Upgrading numpy solved the problem!
Thanks!
On 06/13/13 17:06, Sebastian Berg wrote:
On Thu, 2013-06-13 at 16:50 +0200, Pietro Bonfa' wrote:
Dear Numpy users,
I have a memory leak in my code. A simple way to reproduce my problem is:
import numpy
class test():
def __init__(self):
On Thu, 2013-06-13 at 16:50 +0200, Pietro Bonfa' wrote:
Dear Numpy users,
I have a memory leak in my code. A simple way to reproduce my problem is:
import numpy
class test():
def __init__(self):
pass
def t(self):
temp = numpy.zeros([200,100,100])
A
I've tracked down and fixed a memory leak in 1.7 and master. The pull
request to check and backport is here:
https://github.com/numpy/numpy/pull/2928
Thanks,
Mark
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
Hi list,
I think that I am hit a memory leak with numpy master. The following code
enables to reproduce it:
import numpy as np
n = 100
m = np.eye(n)
for i in range(3):
#np.linalg.slogdet(m)
t, result_t
Hi,
with numpy '1.6.1', I have no problem.
With numpy 1.7.0b2, I can reproduce the problem.
HTH
Fred
On Mon, Sep 24, 2012 at 1:04 PM, Gael Varoquaux
gael.varoqu...@normalesup.org wrote:
Hi list,
I think that I am hit a memory leak with numpy master. The following code
enables to
Hi Fred,
On Mon, Sep 24, 2012 at 02:17:16PM -0400, Frédéric Bastien wrote:
with numpy '1.6.1', I have no problem.
With numpy 1.7.0b2, I can reproduce the problem.
OK, thanks. I think that I'll start a bisect to figure out when it crept
in.
Gael
___
On Mon, Sep 24, 2012 at 7:19 PM, Gael Varoquaux
gael.varoqu...@normalesup.org wrote:
Hi Fred,
On Mon, Sep 24, 2012 at 02:17:16PM -0400, Frédéric Bastien wrote:
with numpy '1.6.1', I have no problem.
With numpy 1.7.0b2, I can reproduce the problem.
OK, thanks. I think that I'll start a
On Mon, Sep 24, 2012 at 7:45 PM, Nathaniel Smith n...@pobox.com wrote:
On Mon, Sep 24, 2012 at 7:19 PM, Gael Varoquaux
gael.varoqu...@normalesup.org wrote:
Hi Fred,
On Mon, Sep 24, 2012 at 02:17:16PM -0400, Frédéric Bastien wrote:
with numpy '1.6.1', I have no problem.
With numpy 1.7.0b2,
On Mon, Sep 24, 2012 at 07:59:11PM +0100, Nathaniel Smith wrote:
which means I probably forgot a DECREF while doing the
PyArray_Diagonal changes...
Yep: https://github.com/numpy/numpy/pull/457
Awesome. I can confirm that this fixes the problem. Script below to check.
You are my hero!
Gael
To: numpy-discussion@scipy.org
Subject: [Numpy-discussion] Memory Leak
The attached program leaks about 24 bytes per loop. The comments give a
bit more detail as to when the leak occurs and doesn't. How can I track
down where this leak is actually coming from?
Here is a sample run on my machine
The attached program leaks about 24 bytes per loop. The comments give a
bit more detail as to when the leak occurs and doesn't. How can I track
down where this leak is actually coming from?
Here is a sample run on my machine:
$ python simple.py
Python Version: 2.7.3 (default, Apr 20 2012,
memory leak was observed in numpy versions 1.5.1 and latest git trunc
from numpy import *
for i in range(10):
if i % 100 == 0:
print(i)
a = empty(1,object)
for j in range(1):
a[j] = array(1)
a = take(a, range(9000),out=a[:9000])
___
Dear Community,
I have an issue with numpy consuming more and more memory.
According to ticket: http://projects.scipy.org/numpy/ticket/1427
This is a known issue. It should be fixed in 2.0.0.dev-9451260. What does this
mean? It sound like a development release.
Is there any chance to fix it in
On Fri, Mar 9, 2012 at 3:07 PM, FRENK Andreas andreas.fr...@3ds.com wrote:
Dear Community,
I have an issue with numpy consuming more and more memory.
According to ticket: http://projects.scipy.org/numpy/ticket/1427
This is a known issue. It should be fixed in 2.0.0.dev-9451260. What
On Thu, May 19, 2011 at 1:53 AM, Pauli Virtanen p...@iki.fi wrote:
On Wed, 18 May 2011 16:36:31 -0700, G Jones wrote:
[clip]
As a followup, I managed to install tcmalloc as described in the article
I mentioned. Running the example I sent now shows a constant memory foot
print as expected.
Hello,
I need to process several large (~40 GB) files. np.memmap seems ideal for
this, but I have run into a problem that looks like a memory leak or memory
fragmentation. The following code illustrates the problem
import numpy as np
x = np.memmap('mybigfile.bin',mode='r',dtype='uint8')
print
On Wed, 18 May 2011 15:09:31 -0700, G Jones wrote:
[clip]
import numpy as np
x = np.memmap('mybigfile.bin',mode='r',dtype='uint8') print x.shape #
prints (42940071360,) in my case ndat = x.shape[0]
for k in range(1000):
y = x[k*ndat/1000:(k+1)*ndat/1000].astype('float32') #The astype
Hello,
I have seen the effect you describe, I had originally assumed this was the
case, but in fact there seems to be more to the problem. If it were only the
effect you mention, there should not be any memory error because the OS will
drop the pages when the memory is actually needed for
On Wed, 18 May 2011 16:36:31 -0700, G Jones wrote:
[clip]
As a followup, I managed to install tcmalloc as described in the article
I mentioned. Running the example I sent now shows a constant memory foot
print as expected. I am surprised such a solution was necessary.
Certainly others must
On Mon, Jul 12, 2010 at 6:44 PM, Nathaniel Peterson
nathanielpeterso...@gmail.com wrote:
Wes McKinney wesmck...@gmail.com writes:
Did you mean to post a different link? That's the ticket I just created :)
How silly of me! I meant http://projects.scipy.org/numpy/ticket/1427
This one was quite a bear to track down, starting from the of course
very high level observation of why is my application leaking memory.
I've reproduced it on Windows XP using NumPy 1.3.0 on Python 2.5 and
1.4.1 on Python 2.6 (EPD). Basically it seems that calling
.astype(bool) on an ndarray
On Mon, Jul 12, 2010 at 2:22 PM, Wes McKinney wesmck...@gmail.com wrote:
This one was quite a bear to track down, starting from the of course
very high level observation of why is my application leaking memory.
I've reproduced it on Windows XP using NumPy 1.3.0 on Python 2.5 and
1.4.1 on
This memory leak may be related: http://projects.scipy.org/numpy/ticket/1542
It shows what appears to be a memory leak when calling astype('float')
on an array of dtype 'object'.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
On Mon, Jul 12, 2010 at 3:39 PM, Nathaniel Peterson
nathanielpeterso...@gmail.com wrote:
This memory leak may be related: http://projects.scipy.org/numpy/ticket/1542
It shows what appears to be a memory leak when calling astype('float')
on an array of dtype 'object'.
Wes McKinney wesmck...@gmail.com writes:
Did you mean to post a different link? That's the ticket I just created :)
How silly of me! I meant http://projects.scipy.org/numpy/ticket/1427
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
Hi all,
I am hitting a memory leak with the combination of numpy and cvxopt.matrix. As
I am not where it occurs, I am cross posting.
On my machine (Fedora 13, x86_64) this example quickly eats up all my memory.
---
from cvxopt import matrix
import numpy as np
N = 2000
X = np.ones((N,
Fri, 02 Jul 2010 14:56:47 +0200, Tillmann Falck wrote:
I am hitting a memory leak with the combination of numpy and
cvxopt.matrix. As I am not where it occurs, I am cross posting.
Probably a bug in cvxopt, as also the following leaks memory:
from cvxopt import
Hello,
I have the following code, where I noticed a memory leak with +=, but
not with + alone.
import numpy
m=numpy.matrix(numpy.ones((23,23)))
for i in range(1000):
m+=0.0 # keeps growing in memory
#m=m+0.0 # is stable in memory
My version of python is 2.5, numpy 1.3.0,
On Fri, May 14, 2010 at 2:43 PM, Brian Blais bbl...@bryant.edu wrote:
Hello,
I have the following code, where I noticed a memory leak with +=, but
not with + alone.
import numpy
m=numpy.matrix(numpy.ones((23,23)))
for i in range(1000):
m+=0.0 # keeps growing in memory
#
On Fri, May 14, 2010 at 3:26 PM, josef.p...@gmail.com wrote:
On Fri, May 14, 2010 at 2:43 PM, Brian Blais bbl...@bryant.edu wrote:
Hello,
I have the following code, where I noticed a memory leak with +=, but
not with + alone.
import numpy
m=numpy.matrix(numpy.ones((23,23)))
for i in
On May 14, 2010, at 16:03 , josef.p...@gmail.com wrote:
On Fri, May 14, 2010 at 3:26 PM, josef.p...@gmail.com wrote:
On Fri, May 14, 2010 at 2:43 PM, Brian Blais bbl...@bryant.edu
wrote:
Hello,
I have the following code, where I noticed a memory leak with +=,
but
not with + alone.
Hi,
I've got two issues:
First, the following seems to cause a memory leak,
using numpy 1.3.0:
a = matrix(ones(1))
while True:
a += 0
This only seems to happen when a is a matrix rather
than an array, and when the short hand '+=' is used.
Second, I'm not sure whether that's a bug or
On Tue, Mar 9, 2010 at 12:31 PM, David Paul Reichert
d.p.reich...@sms.ed.ac.uk wrote:
Hi,
I've got two issues:
First, the following seems to cause a memory leak,
using numpy 1.3.0:
a = matrix(ones(1))
while True:
a += 0
This only seems to happen when a is a matrix rather
than an
Thanks for the reply.
Yes never mind the second issue, I had myself confused there.
Any comments on the memory leak?
On Tue, Mar 9, 2010 at 5:55 PM, josef.p...@gmail.com wrote:
On Tue, Mar 9, 2010 at 12:31 PM, David Paul Reichert
d.p.reich...@sms.ed.ac.uk wrote:
Hi,
I've got two
On Tue, Mar 9, 2010 at 11:31, David Paul Reichert
d.p.reich...@sms.ed.ac.uk wrote:
Hi,
I've got two issues:
First, the following seems to cause a memory leak,
using numpy 1.3.0:
a = matrix(ones(1))
while True:
a += 0
This only seems to happen when a is a matrix rather
than an
On Tue, Mar 9, 2010 at 1:28 PM, Robert Kern robert.k...@gmail.com wrote:
On Tue, Mar 9, 2010 at 11:31, David Paul Reichert
d.p.reich...@sms.ed.ac.uk wrote:
Hi,
I've got two issues:
First, the following seems to cause a memory leak,
using numpy 1.3.0:
a = matrix(ones(1))
while True:
On Tue, Mar 9, 2010 at 13:49, David Reichert d.p.reich...@sms.ed.ac.uk wrote:
Hi,
I just reported a memory leak with matrices, and I might have found
another (unrelated) one in the convolve2d function:
import scipy.signal
from numpy import ones
while True:
Hm, upgrading scipy from 0.7.0 to 0.7.1 didn't do the trick for me (still
running numpy 1.3.0).
I'm not sure if I feel confident enough to use developer versions, but I'll
look into it.
Cheers
David
On Tue, Mar 9, 2010 at 7:57 PM, Robert Kern robert.k...@gmail.com wrote:
On Tue, Mar 9, 2010
On Tue, Mar 9, 2010 at 4:24 PM, David Reichert
d.p.reich...@sms.ed.ac.uk wrote:
Hm, upgrading scipy from 0.7.0 to 0.7.1 didn't do the trick for me (still
running numpy 1.3.0).
I'm not sure if I feel confident enough to use developer versions, but I'll
look into it.
If you don't need the extra
Hi,
Just another update:
signal.convolve and signal.fftconvolve indeed do not seem to have the
problem,
however, they are slower by at least a factor of 2 for my situation.
Moreover, I also tried out the numpy 1.4.x branch and the latest scipy svn,
and a short test seemed to indicate that the
On Tue, Mar 9, 2010 at 7:13 PM, David Reichert
d.p.reich...@sms.ed.ac.uk wrote:
Hi,
Just another update:
signal.convolve and signal.fftconvolve indeed do not seem to have the
problem,
however, they are slower by at least a factor of 2 for my situation.
Moreover, I also tried out the numpy
I opened a ticket for this (#602). Hopefully someone will confirm that adding
that Py_DECREF call fixes the leak and someone with write access patches it
in svn.
- Karol
--
written by Karol Langner
Sun Oct 28 23:29:18 EDT 2007
___
Numpy-discussion
Karol Langner wrote:
I opened a ticket for this (#602). Hopefully someone will confirm that adding
that Py_DECREF call fixes the leak and someone with write access patches it
in svn.
Thanks for looking into this and isolating the problem...
-Travis O.
Hi Karol
Thank you very much for the sleuth work here. We are in the midst of
software ATP so it helps a lot that I will be able to resolve this bug
properly.
Robert
On 10/29/07, Karol Langner [EMAIL PROTECTED] wrote:
I opened a ticket for this (#602). Hopefully someone will confirm that
On Friday 26 October 2007 05:39, Robert Crida wrote:
Hi all
I recently posted about a memory leak in numpy and failed to mention the
version. The leak manifests itself in numpy-1.0.3.1 but is not present in
numpy-1.0.2
The following code reproduces the bug:
import numpy as np
a =
Hi all
I seem to have tracked down a memory leak in the string conversion mechanism
of numpy. It is demonstrated using the following code:
import numpy as np
a = np.array([1.0, 2.0, 3.0])
while True:
b = str(a)
What happens above is that is repeatedly converted to a string. The process
Robert Crida wrote:
Hi all
I seem to have tracked down a memory leak in the string conversion
mechanism of numpy. It is demonstrated using the following code:
import numpy as np
a = np.array([1.0, 2.0, 3.0])
while True:
b = str(a)
What happens above is that is repeatedly converted
Hi all
I recently posted about a memory leak in numpy and failed to mention the
version. The leak manifests itself in numpy-1.0.3.1 but is not present in
numpy-1.0.2
The following code reproduces the bug:
import numpy as np
a = np.array([1.0, 2.0, 3.0])
while True:
b = str(a)
What happens
Which version Python are you using ?
Matthieu
2007/10/26, Robert Crida [EMAIL PROTECTED]:
Hi all
I recently posted about a memory leak in numpy and failed to mention the
version. The leak manifests itself in numpy-1.0.3.1 but is not present in
numpy-1.0.2
The following code reproduces
Hi
I don't think it is a python issue because if you change the line b = str(a)
to just read
str(a)
then the problem still occurs.
Also, if you change a to be a list instead of ndarray then the problem does
not occur.
Cheers
Robert
On 10/26/07, Matthew Brett [EMAIL PROTECTED] wrote:
Hi,
Robert Crida wrote:
Hi
I don't think it is a python issue because if you change the line b =
str(a) to just read
str(a)
then the problem still occurs.
Also, if you change a to be a list instead of ndarray then the problem
does not occur.
How do you know there is a memory leak ?
On 10/26/07, Robert Crida [EMAIL PROTECTED] wrote:
Hi again
I watch the VmSize of the process using eg top or ps
If a is a list then it remains constant. If a is an ndarray as shown in the
example, then the VmSize grows quite rapidly.
Actually, I did a typo while copying your example. I can
On 10/26/07, David Cournapeau [EMAIL PROTECTED] wrote:
On 10/26/07, Robert Crida [EMAIL PROTECTED] wrote:
Hi again
I watch the VmSize of the process using eg top or ps
If a is a list then it remains constant. If a is an ndarray as shown in the
example, then the VmSize grows quite
I can confirm the same behaviour with numpy '1.0.4.dev4271' on OS X
10.4with python
2.5.1 (installer from python.org).
For me the memory used by the python process grows at about 1MB/sec. The
memory isn't released when the loop is canceled.
___
On 10/26/07, Robert Crida [EMAIL PROTECTED] wrote:
Hi all
I recently posted about a memory leak in numpy and failed to mention the
version. The leak manifests itself in numpy-1.0.3.1 but is not present in
numpy-1.0.2
The following code reproduces the bug:
import numpy as np
a =
Hello,
the following code seems to create a memory leak in Python.
(around 230 MB).
Any ideas what's wrong ?
I'm using python 2.5 and numpy 1.0.3
---
def toto(x):
return x**2
tutu=vectorize(toto)
Nbins=1
for i in xrange(1000):
c=tutu(arange(Nbins))
Thomas J. Duck wrote:
Hi,
There seems to be a memory leak when arrays are added in-place
for mixed Numeric/numpy applications. For example, memory usage
quickly ramps up when the following program is executed:
import Numeric,numpy
x =
Hi,
There seems to be a memory leak when arrays are added in-place
for mixed Numeric/numpy applications. For example, memory usage
quickly ramps up when the following program is executed:
import Numeric,numpy
x = Numeric.zeros((2000,2000),typecode=Numeric.Float64)
for j in
Hi,
I'm not sure this is the right mailing list for this, but it seems
there's a memory leak when looking at flags :
from numpy import *
x=ones(5000) #== python use 25% of memory (ok)
del x
#== memory usage fall back to almost zero (as seen in top)
Thqt's good.
but if I look at
Cyrille Rosset wrote:
Hi,
I'm not sure this is the right mailing list for this, but it seems
there's a memory leak when looking at flags :
from numpy import *
x=ones(5000) #== python use 25% of memory (ok)
del x
#== memory usage fall back to almost zero (as seen in top)
Ok, that works fine with python.
But not in ipython... is there some other trick ?
(there's a whole collection of _* variables in there...)
Cyrille.
Robert Kern a écrit :
Cyrille Rosset wrote:
Hi,
I'm not sure this is the right mailing list for this, but it seems
there's a memory leak when
Cyrille Rosset wrote:
Ok, that works fine with python.
But not in ipython... is there some other trick ?
(there's a whole collection of _* variables in there...)
And the Out[NN]'s, too. You should be able to del all of them:
del Out[NN], _NN, _, __, ___
--
Robert Kern
I have come to
I'm not sure where best to post this, but I get a memory leak when using
code with both numpy and FFT(from Numeric) together:
e.g.
import numpy
import FFT
def test():
... while 1:
... data=numpy.random.random(2048)
... newdata = FFT.real_fft(data)
test()
and memory
Bryan Cole wrote:
I'm not sure where best to post this, but I get a memory leak when using
code with both numpy and FFT(from Numeric) together:
e.g.
import numpy
import FFT
def test():
... while 1:
... data=numpy.random.random(2048)
... newdata =
This eats up memory quickly on my system.
import numpy.matlib as M
def memleak():
a = M.randn(500, 1)
while True:
a = a.argsort(0)
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
El dl 05 de 02 del 2007 a les 08:45 -0800, en/na Keith Goodman va
escriure:
This eats up memory quickly on my system.
import numpy.matlib as M
def memleak():
a = M.randn(500, 1)
while True:
a = a.argsort(0)
Yeah, the guilty in this case is argsort():
On 2/5/07, Francesc Altet [EMAIL PROTECTED] wrote:
El dl 05 de 02 del 2007 a les 08:45 -0800, en/na Keith Goodman va
escriure:
This eats up memory quickly on my system.
import numpy.matlib as M
def memleak():
a = M.randn(500, 1)
while True:
a = a.argsort(0)
87 matches
Mail list logo
