Tcl is blameless, apparently

From: John Seal (sealj_at_indy.raytheon.com)
Date: 02/28/05 

Date: Mon, 28 Feb 2005 14:01:08 -0500

The latest release of our product showed a puzzling slowdown in the
subsystem I'm responsible for, which is written in Tcl/Tk. Suspicion
fell on a recent Tcl version upgrade, but apparently it wasn't the culprit.

A little background: I started development with ActiveTcl 8.3.4.1, and
never upgraded. A couple years ago I wrote a Problem Report (which is
also the mechanism for requesting enhancements) saying that we ought to
upgrade to a more recent version of Tcl. I said that by upgrading we
would reap the benefit of speedups and bugfixes without having to change
the source code at all, but that we might exploit new features for even
greater speed, e.g., using [lset] instead of [set ... [lreplace ...]],
which we do all over the place with big, big lists. The "powers that
be" resisted for a long time, on the theory that if it ain't broke,
don't mess with it, but recently agreed to allow it for the new release.

With this release there were MAJOR changes OUTSIDE of my subsystem, but
only one within it: upgrading Tcl from 8.3.4 to 8.4.7. The outside
changes included recompiling certain clients of my subsystem to run on
Solaris 9 instead of Solaris 2.6, use of 100baseT and switches instead
of 10base2, and replacement of all the screens we display on with RAVE
workstations running Solaris 9 instead of a mix of HP-UX boxen and X
terminals. My code runs on a pair of SPARC cards running Solaris 2.6
and talking to various hardware via HP-IB, RS-232, parallel port, and
network sockets. All of my GUIs display remotely on a bunch of RAVE
workstations. (Now that we have beefy RAVEs instead of the wimpy HP-UX
boxes, I want to distribute the execution of the code among the
workstations, but that's for another release....)

Anyway, when we finally got around to stress testing the new
configuration, we found it was reaching 0% idle in circumstances that
used to have 70-80% idle. Using the old diagnostic technique that if it
used to work, and now it doesn't, what's changed? I guessed it was 1)
Tcl, 2) the network, or 3) the RAVEs. Well, it apparently was 4) none
of the above. At this point it seems to be the two external clients
that were recompiled (two per workstation, that is). I'm not sure what
they're doing to cause it, though. They're supposed to connect once at
system startup, and the data rate is pretty low and sporadic. They are
connecting, and everything that's supposed to work is working, but kill
those processes and my subsystem speeds up again back to normal! Hmmm.

If anything interesting comes out of our analysis, I'll let the group know.

Quantcast