> From: eryk...@gmail.com
> Date: Thu, 14 Jan 2016 04:42:57 -0600
> Subject: Re: [Tutor] Question about the memory manager
> To: tutor@python.org
> CC: sjeik_ap...@hotmail.com
>
> On Thu, Jan 14, 2016 at 3:03 AM, Albert-Jan Roskam
> wrote:
> >
> > These two p
On Thu, Jan 14, 2016 at 3:03 AM, Albert-Jan Roskam
wrote:
>
> These two pages are quite nice. The author says the memory used by small
> objects is
> never returned to the OS, which may be problematic for long running processes.
The article by Evan Jones discusses a patch to enable releasing unu
D
> From: sjeik_ap...@hotmail.com
> To: tim.pet...@gmail.com
> Date: Wed, 13 Jan 2016 08:11:11 +
> Subject: Re: [Tutor] Question about the memory manager
> CC: tutor@python.org
>
> > From: tim.pet...@gmail.com
> > Date: Sun, 10 Jan 2016 10:54:10 -0600
> >
On Wed, Jan 13, 2016 at 2:01 AM, Albert-Jan Roskam
wrote:
> I sometimes check the Task Manager to see how much RAM is in use. Is there a
> Python way to do something similar?
Use the psutil module to solve this problem across platforms. For
Windows only, you can use ctypes to call GetProcessMemo
> From: tim.pet...@gmail.com
> Date: Sun, 10 Jan 2016 10:54:10 -0600
> Subject: Re: [Tutor] Question about the memory manager
> To: sjeik_ap...@hotmail.com
> CC: tutor@python.org
>
> [Albert-Jan Roskam ]
> > I just found a neat trick to free up an emergency stash of m
> To: tutor@python.org
> From: __pete...@web.de
> Date: Sun, 10 Jan 2016 18:29:06 +0100
> Subject: Re: [Tutor] Question about the memory manager
>
> Albert-Jan Roskam wrote:
>
> > Hi,
> >
> > I just found a neat trick to free up an emergency stash of
On 11 January 2016 at 15:40, Peter Otten <__pete...@web.de> wrote:
>> I can't even work out how you trigger a MemoryError on Linux (apart
>> from just raising one). I've tried a few ways to make the system run
>> out of memory and it just borks the system rather than raise any error
>> - I can only
Oscar Benjamin wrote:
> On 11 January 2016 at 12:15, Alan Gauld wrote:
>>
>> But I think that it definitely is heavily OS dependent.
>> It should work in most *nix environments the first time
>> you call the function. But on second call I'd expect
>> all bets to be off. And in most real-time OS's
On 11 January 2016 at 12:15, Alan Gauld wrote:
>
> But I think that it definitely is heavily OS dependent.
> It should work in most *nix environments the first time
> you call the function. But on second call I'd expect
> all bets to be off. And in most real-time OS's memory
> goes right back to t
On 10/01/16 16:16, Steven D'Aprano wrote:
>> rainydayfund = [[] for x in xrange(16*1024)] # or however much you need
>> def handle_exception(e):
>> global rainydayfund
>> del rainydayfund
>> ... etc, etc ...
>
> I was going to write a scornful email about how useless this would be.
Me too.
> st
If you read the comment that goes with the code snippet pasted in the
original email it makes far more sense as the author is talking
specifically about out of memory errors...
"You already got excellent answers, I just wanted to add one more tip
that's served me well over the years in a variety
Albert-Jan Roskam wrote:
> Hi,
>
> I just found a neat trick to free up an emergency stash of memory in a
> funtion that overrides sys.excepthook. The rationale is that all
> exceptions, including MemoryErrors will be logged. The code is below. My
> question: is that memory *guaranteed* to be fre
[Albert-Jan Roskam ]
> I just found a neat trick to free up an emergency stash of memory in
> a funtion that overrides sys.excepthook. The rationale is that all
> exceptions, including MemoryErrors will be logged.
> The code is below. My question: is that memory *guaranteed* to be
> freed right aft
On Sun, Jan 10, 2016 at 11:53:22AM +, Albert-Jan Roskam wrote:
> Hi,
>
> I just found a neat trick to free up an emergency stash of memory in a
> funtion that overrides sys.excepthook.
> rainydayfund = [[] for x in xrange(16*1024)] # or however much you need
> def handle_exception(e):
> glob
Hi,
I just found a neat trick to free up an emergency stash of memory in a funtion
that overrides sys.excepthook. The rationale is that all exceptions, including
MemoryErrors will be logged.
The code is below. My question: is that memory *guaranteed* to be freed right
after the 'del' statement?
15 matches
Mail list logo