[Xastir] Memory question

[Tom Robson, ve7did]

On September 29, 2004 10:53 pm, Tom Russo wrote:
> On Wed, Sep 29, 2004 at 09:47:36PM -0700, a Mr. Richard Feyler of Fort Lee, 
New Jersey <ve7did at dccnet.com> writes 'Dear Rosanne Rosannadanna':
> > > Are you running the CVS version of xastir?  When was the last time you
> > > built it?
> >
> > Yes, I am using cvs... built on Sept 13th.
>
> Hmmm.  Odd.  That rules out the old dbfawk leaks, then --- those were
> cleared up months ago.
>
> > > There could be a new memory leak in some aspect.  How many shapefiles
> > > do you load?  Do you use dbfawk or do you configure with
> > > --disable-dbfawk? Have you tried running with a lighter-weight desktop
> > > than KDE?  Is the behavior the same?
> >
> > I don't routinely run shapefiles because the repositioning is a bit slow,
> > but use them quite often when I want some street detail etc.  I have run
> > about 6 shapefiles but they are about 20Mb each (the *.shp files).  I do
> > use dbfawk for gathering street names.
>
> That's a very small number of shapefiles to take up that much core.  I have
> all the tiger shapefiles for my state, and frequently zoom out to state
> level.  Most are under 10MB, but a few are as large as 14MB, but there's
> 33 of them.  Even when I'm just zoomed in to my own area for a long time
> I've still got about 10 shapefiles on screen (my county shapefile, a bunch
> of USGS data, the National Atlas wilderness area map, a USFS trail map, and
> assorted point shapefiles).  I've never seen the code go as high as 262MB
> even when dbfawk was leaking core like a sieve.
>
> Are your 6 20MB shapefiles all visible at once or are some of them
> completely off screen?

They are all visible if I zoom out.


>
> > I should have mentioned when the maps consume the memory initially and if
> > I deselect them (memory useage does not drop), then select them again the
> > memory useage does not go any higher.  It is as if the maps have reserved
> > the memory space for each map.
>
> Well, that's certainly not *explicitly* the case in xastir --- the maps are
> loaded one at a time, painted into the fixed pixmap, the map is closed, and
> then after all maps are drawn into the pixmap the pixmap is blatted to the
> window.  But it does, of course, have to allocate some memory as it reads
> things in.   Some of what you're seeing (the bit where select, deselect,
> select again neither reduces nor increases memory use) makes sense --- when
> maps are first loaded the code asks for memory from the OS, gets it, uses
> it, and "frees" it, but the memory isn't actually returned to the OS --- 
> it's just marked as free so that when the code asks for more later it gets
> bits of the freed memory first before the OS gives more.  But there's no
> way that accounts for the degree of bloat you're seeing.
>
> I'm interested to see whether your behavior is significantly different with
> a light-weight desktop environment like fvwm or icewm.

Did not make any difference.  Used the cholesterol free desktop (think that is 
icewm)

  My experience with
> KDE is not extensive --- just enough to know it's too bloated for my
> tastes.
>
> Looking for other possible culprits: what versions of shapelib and pcre are
> you using?  If you disable dbfawk at configure time (--without-dbfawk) does
> the behavior stay the same?  Has it done this for very long, or did you
> just notice it?  If you cvs update to today's version does it still bloat?

Used the same cvs from Sept 10th   & configured without dbfawk...  no 
difference. (wanted to keep the variables to a minimum)  It may have been 
doing this for a while, just never noticed until the box became sluggish.

Shapelib  1.2.10
PCRE 4.4

I'll use the latest cvs tomorrow if I get a chance.   Hope I'm not taking you 
up the garden path.

...73 Tom