WeatherWatcherLive Memory Usage


How much memory should WWL be using on a steady state basis? I am running 6.0.26. When I first loaded WWL I was pleased to see that it was only using about 7.5 MB. Over the course of a day it was up to consuming 30 MB. I shut it down and restarted it. Once again the memory consumption was about 7.5 MB. In about 5 minutes it was back up over 30 MB. Is this expected? Thanks, in advance, for any insight.

Which version of Windows and Internet Explorer are you using?

Running XP Service Pack 3

IE 6.0.2900.5512 but I use Firefox 3.0.10 as my browser

After seeing this thread, I started monitoring WWL memory use and saw the same effects: 35MB (working set size) at first but dropped down to 9MB after exit/restart. As I continued monitoring over several hours, it climbed to 29MB (a little higher while DL.EXE was running).

Then I happened to switch weather stations to check whether alerts were working properly (they were), and after switching back I found memory use back down to <7MB! Could it be that the gradual memory growth is related to accumulating log data? Seems like excessive memory for that purpose, especially since I don’t have logging turned on.

I’m going to wait a couple of hours to see if it grows again, and then retest switching stations to see if it shrinks again. I’ll report back.

(My configuration: WWL 6.0.26, XP Home +SP3, IE 8)

I’ve done some more experimenting, and it appears that the figures for the working set size go up and down somewhat chaotically, partly in response to memory demands by other applications and probably partly as a result of VB heap compaction. I suspect, therefore, that the 30 or 35MB figures don’t negatively impact the system very much.

One thing I did discover is that while WWL is running in the tray with no Main window open, the working set is relatively small, around 10MB. When you open the Main window, it balloons by around 20-25MB, but if you then close the Main window (i.e. minimize it to the tray) the working set returns to about its previous value.

However, if you open the Main window and then open either a Map Viewer or the Options window, and then close the Main window without closing the other, the working set does not shrink, and even if you then close the other window it remains high. This can be corrected by re-opening and then closing the Main window. I can see why you wouldn’t want the Map Viewer to be application-modal (so you can switch back to the Main window and select a different map) and why you wouldn’t always want the Options window to be application-modal (because it can be opened from the tray icon menu), but it might be better if unloading the Main window form forced them to unload first. No doubt what’s happening is related to orphaned handles. Fortunately, no memory leak seems to be involved.

Yes, this generally matches the behavior I have observed, except the steady state memory usage I observe is 12-15MB while WWL is running in the tray. It starts out much lower, about 7MB, but rapidly climbs. Opening the main window causes a big jump in memory consumption and closing it reduces it, although not quite down to the original level.

Running this memory cleaner significantly reduces the memory profile, but only temporarily. If it is the VB heap using the memory, it grows much more quickly than it compresses.

This is a much better memory cleaning tool and works as a scheduled task every 30 minutes.