[Xastir-dev] Xastir a CPU pig again?

[Tom Russo]

On Thu, Dec 25, 2003 at 11:53:29AM -0700, a Mr. Richard Feyler of Fort Lee, New Jersey <russo at bogoflux.losalamos.nm.us> writes 'Dear Rosanne Rosannadanna':
> After the "nexttime=2" fix back in late November I got too busy to mess with
> xastir anymore, and hadn't rebuilt from CVS since then.  For the whole
> time since then, xastir has taken less than 1% of the CPU except when it's 
> reading maps.  I built last night, and all of a sudden Xastir is back to 
> taking up in excess of 70% of the CPU time.

BTW, this is on FreeBSD, a 2.6 GHz processor, and with a KPC3+ TNC.

> Has anyone else who saw the CPU burning up before the "nexttime=2" fix seen 
> this happen?  Anyone have a clue what has changed since November 29th that 
> would have caused such a massive performance hit?

I did a bunch of cvs checkout -D "..."'s to try to find when this happened.

I built the version from 1 Dec, and found it *also* burned up the CPU.  The 
previous version I'd had built on 29 Nov didn't.  

Turns out that building the 1 Dec version against the CVS version of gdal
was the problem here --- until last night the only version of gdal I had on my
system was 1.1.9, the last release.  I had installed the new cvs version of
gdal to start playing with the new OGR-enabled xastir code.  When I removed 
the new CVS version of gdal and re-installed version 1.1.9, the 1 Dec version 
of Xastir stopped eating CPU.  It's now running at 0.1-0.2%.  Guess I am 
stuck without cutting edge gdal features for a while.  All other testing was
done with gdal-1.1.9 to eliminate that as an issue.

Backing out the GDAL version does not fix the current CVS version of xastir, 
though.  Even built against gdal-1.1.9, it still eats CPU at a rate of 70%.  
So, too, does a version from 8 Dec.   But the version from 4 Dec does *not* 
do this.

Anyone have an idea where to look?  Clearly it's a change that happened 
between 4 and 8 Dec.  

I briefly suspected an inter-character pacing issue, as the versions earlier
than 8 Dec take a great deal longer to get through the TNC interface 
initialization strings than either the 8 Dec or 25 Dec versions, but the 
timing slider seems to have no effect.  Prior to the implementation of the
pacing slider, what was the inter-char delay?

I did notice, however, that the ballooning of CPU usage occurs as soon as
the initialization of the TNC is done and the first posit is transmitted.  
Until that moment the CPU usage is below 20% and drifting down.

BTW, in trying all this, I had tried to configure xastir with "--without-gdal"
only to find that there is no such option recognized.  xastir's configure
will build against any installed gdal and not allow configure-time disabling
of it.  

-- 
Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://www.qsl.net/~km5vy/
 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]