You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(33) |
Dec
(20) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(7) |
Feb
(44) |
Mar
(51) |
Apr
(43) |
May
(43) |
Jun
(36) |
Jul
(61) |
Aug
(44) |
Sep
(25) |
Oct
(82) |
Nov
(97) |
Dec
(47) |
2005 |
Jan
(77) |
Feb
(143) |
Mar
(42) |
Apr
(31) |
May
(93) |
Jun
(93) |
Jul
(35) |
Aug
(78) |
Sep
(56) |
Oct
(44) |
Nov
(72) |
Dec
(75) |
2006 |
Jan
(116) |
Feb
(99) |
Mar
(181) |
Apr
(171) |
May
(112) |
Jun
(86) |
Jul
(91) |
Aug
(111) |
Sep
(77) |
Oct
(72) |
Nov
(57) |
Dec
(51) |
2007 |
Jan
(64) |
Feb
(116) |
Mar
(70) |
Apr
(74) |
May
(53) |
Jun
(40) |
Jul
(519) |
Aug
(151) |
Sep
(132) |
Oct
(74) |
Nov
(282) |
Dec
(190) |
2008 |
Jan
(141) |
Feb
(67) |
Mar
(69) |
Apr
(96) |
May
(227) |
Jun
(404) |
Jul
(399) |
Aug
(96) |
Sep
(120) |
Oct
(205) |
Nov
(126) |
Dec
(261) |
2009 |
Jan
(136) |
Feb
(136) |
Mar
(119) |
Apr
(124) |
May
(155) |
Jun
(98) |
Jul
(136) |
Aug
(292) |
Sep
(174) |
Oct
(126) |
Nov
(126) |
Dec
(79) |
2010 |
Jan
(109) |
Feb
(83) |
Mar
(139) |
Apr
(91) |
May
(79) |
Jun
(164) |
Jul
(184) |
Aug
(146) |
Sep
(163) |
Oct
(128) |
Nov
(70) |
Dec
(73) |
2011 |
Jan
(235) |
Feb
(165) |
Mar
(147) |
Apr
(86) |
May
(74) |
Jun
(118) |
Jul
(65) |
Aug
(75) |
Sep
(162) |
Oct
(94) |
Nov
(48) |
Dec
(44) |
2012 |
Jan
(49) |
Feb
(40) |
Mar
(88) |
Apr
(35) |
May
(52) |
Jun
(69) |
Jul
(90) |
Aug
(123) |
Sep
(112) |
Oct
(120) |
Nov
(105) |
Dec
(116) |
2013 |
Jan
(76) |
Feb
(26) |
Mar
(78) |
Apr
(43) |
May
(61) |
Jun
(53) |
Jul
(147) |
Aug
(85) |
Sep
(83) |
Oct
(122) |
Nov
(18) |
Dec
(27) |
2014 |
Jan
(58) |
Feb
(25) |
Mar
(49) |
Apr
(17) |
May
(29) |
Jun
(39) |
Jul
(53) |
Aug
(52) |
Sep
(35) |
Oct
(47) |
Nov
(110) |
Dec
(27) |
2015 |
Jan
(50) |
Feb
(93) |
Mar
(96) |
Apr
(30) |
May
(55) |
Jun
(83) |
Jul
(44) |
Aug
(8) |
Sep
(5) |
Oct
|
Nov
(1) |
Dec
(1) |
2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
|
|
1
(1) |
2
(7) |
3
|
4
|
5
(16) |
6
(11) |
7
|
8
(1) |
9
(4) |
10
(10) |
11
|
12
(4) |
13
(4) |
14
(5) |
15
(5) |
16
(11) |
17
(3) |
18
(2) |
19
(5) |
20
(2) |
21
(5) |
22
(2) |
23
(2) |
24
|
25
|
26
(4) |
27
(8) |
28
(9) |
29
(9) |
30
(5) |
31
(1) |
I'm not able to see this here (RHEL 4, matplotlib SVN trunk) with either the PDF or TkAgg backends. The attached graphs show that memory usage levels off after the first 3-4 iterations. I only did 10 iterations here to save bandwidth, but I also tested 500 and the results were the same. As I'm not on a Mac, I'm unable to test the Cocoa backend. What tool are you using to detect the memory leaks? Many tools that work at the high level (such as Windows Task Manager etc.) are full of pitfalls, so in my experience you really need to use a tool designed for the purpose of detecting memory leaks (such as Valgrind/Massif, or the Apple one whose name escapes me). I modified Damon's script to use random data (since his data was not attached). If this script does not leak memory for either of you, then perhaps the leak is data-dependent, in which case I'll either need to obtain or better simulate that data. Mike Michiel de Hoon wrote: > I am also finding the continuing increase in memory usage, but this also occurs with other backends (I tried tkagg and pdf) and also without the call to savefig. One possibility is a circular reference in the quiver function that prevents data from being cleaned up. > > --Michiel > > > --- On Mon, 1/19/09, Damon McDougall <dam...@gm...> wrote: > > >> From: Damon McDougall <dam...@gm...> >> Subject: [matplotlib-devel] Memory leak using savefig with MacOSX backend? >> To: "matplotlib development list" <mat...@li...> >> Date: Monday, January 19, 2009, 6:09 AM >> I'm looping over several files (about 1000) to produce a >> vector field plot for each data file I have. Doing this with >> the MacOSX backend appears to chew memory. My guess as to >> the source of the problem is the 'savefig' function >> (or possibly the way the MacOSX backend handles the saving >> of plots). >> >> I opened Activity Monitor to watch the usage of memory >> increase. Below is code that recreates the problem. >> >> [start] >> >> import matplotlib >> matplotlib.use('macosx') >> matplotlib.rc('font',**{'family':'serif','serif':['Computer >> Modern Roman']}) >> matplotlib.rc('text', usetex=True) >> from pylab import * >> >> i = 0 >> x = [] >> y = [] >> v1 = [] >> v2 = [] >> >> while(True): >> f = open("%dresults.dat"%i,"r") >> for line in f: >> x.append(float(line.split()[0])) >> y.append(float(line.split()[1])) >> v1.append(float(line.split()[2])) >> v2.append(float(line.split()[3])) >> f.close() >> hold(False) >> figure(1) >> quiver(x, y, v1, v2, color='b', >> units='width', scale=1.0) >> xlabel('$x$') >> ylabel('$y$') >> grid(True) >> print i >> savefig('graph-%05d.pdf'%i) >> close(1) >> x = [] >> y = [] >> v1 = [] >> v2 = [] >> i = i + 1 >> >> >> [end] >> >> Regards, >> --Damon >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword_______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
> Thanks for looking into this! The new plot is much improved, and the > simplified calculations are a pleasant surprise. I was also testing the > previous algorithm with solid_joinstyle set to "round" as it is the > default in my matplotlibrc. > > I am probably not able to build your patch here, unless building > matplotlib from source on Windows is easier than I anticipate. May I > send you some data off the list for you to test? > No problem. I'd also want testing from others -- there aren't a lot of examples in matplotlib itself where simplification even kicks in. Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA