From: derek b. <d_b...@ho...> - 2004-02-09 15:17:24
|
<html><div style='background-color:'><DIV class=RTE> <P>I am interested in using Matplotlib for real-time updating plot applications. My concern is with system load issues (they're pretty high). Using the code below, which came off of an earlier posting to this list, on a pc (2.4 gig processor) memory usage ranges from 20 - 50+ megs (there's a cycling pattern) and 30-40% of the cpu is being used for this basic app. If left to run for 20 minutes or so, it seems to crash (entire screen turns grey and reboot is required to get machine back to working order).</P> <P>On a solaris machine, the performance numbers are similar, though the memory didn't appear to exceed 30 megs (or cycle). One other solaris issue is that the plot doesn't update, unless it is forced to redraw (by moving another window over the plot window). I've tinkered with the redraw rate, but it didn't seem to help.</P> <P>Short of the performance issues, this software looks great. Is there a way of using the software that will minimize system impact, or better yet, can this become a development priority? It's not clear if the performance issue is driven by matplotlib, pygtk or gtk. Is it possible that different backends lead to non-trivial differences in performance? </P> <P>Also, the crashing on a pc and non-updating on solaris are outstanding concerns.</P> <P>Derek Bandler</P> <P>####</P> <P>import pygtk<BR>pygtk.require('2.0')<BR>import gtk<BR>import time<BR>from matplotlib.matlab import *<BR> <BR>def get_memory():<BR> "Simulate a function that returns system memory"<BR> return 100*(1+sin(0.5*pi*time.time()))<BR> <BR>def get_cpu():<BR> "Simulate a function that returns cpu usage"<BR> return 100*(1+sin(0.2*pi*(time.time()-0.25)))<BR> <BR>def get_net():<BR> "Simulate a function that returns network bandwidth"<BR> return 100*(1+sin(0.7*pi*(time.time()-0.1)))<BR> <BR>def get_stats():<BR> return get_memory(), get_cpu(), get_net()<BR> <BR>fig = figure(1)<BR>ax = subplot(111)<BR>ind = arange(1,4)<BR>pm, pc, pn = bar(ind, get_stats())<BR>centers = ind + 0.5*pm.get_width()<BR>pm.set_facecolor('r')<BR>pc.set_facecolor('g')<BR>pn.set_facecolor('b')</P> <P>ax.set_xlim([0.5,4])<BR>ax.set_xticks(centers)<BR>ax.set_ylim([0,100])<BR>ax.set_xticklabels(['Memory', 'CPU', 'Bandwidth'])<BR>ax.set_ylabel('Percent usage')<BR>ax.set_title('System Monitor')<BR> <BR>def updatefig(*args):<BR> m,c,n = get_stats()<BR> pm.set_height(m)<BR> pc.set_height(c)<BR> pn.set_height(n)<BR> ax.set_ylim([0,100])</P> <P> fig.draw()<BR> <BR> return gtk.TRUE</P> <P>gtk.timeout_add(250, updatefig)<BR>show()</P></DIV></div><br clear=all><hr> <a href="http://g.msn.com/8HMBENUS/2752??PS=">Create your own personal Web page with the info you use most, at My MSN.</a> </html> |
From: John H. <jdh...@ac...> - 2004-02-09 15:36:08
|
>>>>> "derek" == derek bandler <d_b...@ho...> writes: derek> I am interested in using Matplotlib for real-time derek> updating plot applications. My concern is with system load derek> issues (they're pretty high). Using the code below, which derek> came off of an earlier posting to this list, on a pc (2.4 derek> gig processor) memory usage ranges from 20 - 50+ megs derek> (there's a cycling pattern) and 30-40% of the cpu is being derek> used for this basic app. If left to run for 20 minutes or derek> so, it seems to crash (entire screen turns grey and reboot derek> is required to get machine back to working order). I answered this problem on the support request you submitted to sourceforge a couple of days ago. I'll paste in my response from the sourceforge site Date: 2004-02-06 14:22 Sender: jdh2358 Logged In: YES user_id=395152 Thanks for the bug report! I have spent a lot of time optimizing matplotlib for pltotting and interacting with large data sets, but not for frequently redrawing small data sets. Fortunately, I was able to replicate the bug on my system. I identified a memory leak in pygtk in a function I use for rotating tick labels. It turns out almost all the CPU usuage (and memory) was for repeatedly computing layout information, rotations, and so on for text onthe tick labels. Since these rarely change (eg, in system demo) I cache all the relevant information. I also cache the result that is causing the memory leak in pygtk, so repeated calls will not drain memory. The result is a system demo with CPU usage reduced from 30-40% to 4-8% and memory consumption reduced from a growing memory leak to a stable 1.2%. Not bad. Please let me know if you continue to experience performance issues. I I have updated CVS. I you have trouble accessing CVS, email me at jdh...@ac... and I'll send you a snapshot. I have no idea about the solaris redraw problem currently JDH Date: 2004-02-06 15:51 Sender: jdh2358 Logged In: YES user_id=395152 I tracked down the memory leak in pygtk. I you are intersting in patching your pygtk, the bug report and patch are here http://bugzilla.gnome.org/show_bug.cgi?id=133681 |