DN640160310

Subject: Re: How fast is tcl? - DN [1]

De Clarke <de@yakuza.ucolick.org> - 28 Jun 2000 - comp.lang.tcl

 willlahr@my-deja.com wrote:
 : Hi,

 : What can be done to reduce any delay to the bare
 : minimum?

 : For example is it best when running a number of
 : scripts sequentially to use the same interpreter
 : over and over again or do old interpreters slow
 : down script start up (as they may hold more
 : procedures & global variables etc)?

 I don't believe you mentioned your OS or the scale and
 nature of your problem.  I am by no means a performance geek,
 nor can I speak for environments other than Unix, so ymmv.
 But performance is of some concern to us here, so I've done
 small amounts of thinking about it.

 In general we work in large-memory environments (256MB is
 not unusual for one of our production machines and 128MB is
 about standard) with a lot of fast disk space (10GB is
 a minimalist system).  CPU power ranges from dual PII
 to PIII to multi-processor Sparc servers and big DEC
 (sorry, Compaq) Alphas.  Therefore our perception of
 performance is conditioned by an environment in which
 disk, memory, and brute CPU power are "cheap," i.e.
 already required for other project goals, therefore accessible
 to the tcl programs which form part of the delivered
 project.

 We don't use tcl scripts for large apps, i.e. our large
 apps are not a collection of independent tcl scrips being
 exec'd one after another.  They are large libraries of
 tcl *procs* being called by a main, very much like any
 other procedural language...  we think of them as
 Tcl programs more than as Tcl "scripts", though this is
 a dubious distinction for a "scripting" language :-)

 Sorry for the lengthiness of this post, but when you ask "is
 Tcl fast?" it's a rather deep question.  If you have enough
 hardware to throw at the problem, most any language is fast
 enough, and you make language choices based on things like
 time from prototype to deliverable, learning curve, flexibility,
 legibility, maintainability, existing expertise, etc.  Then
 imho Tcl/Tk wins, bigtime.  If you are hardware-poor and
 trying to cobble together a performance-critical app on a
 486 with 16MB, you're in a different world from mine and
 very little that I say may be relevant.

 ---------

 What I can tell you about Tcl/Tk performance here is that
 I use the language to construct GUIs for realtime systems
 where the asynch event rate is about 1Hz per datum, with
 in theory 400-500 of these data changing independently.

 This is not quite honest, however :-) the backend processes
 are actually clumping updates of whole groups of data on
 the 1Hz clock.  Given the number of backend processes I
 would guesstimate the *actual* event rate, in network
 performance terms, to be about 4 or 5 Hz (a moderate burst
 of activity about 4 or 5 times/sec).  I'm embarrassed to
 admit that I don't know how many actual callbacks in the
 interp event loop are caused by each burst, but anywhere from
 a few to a couple of hundred global variables are set (call
 to Tcl interp set global var routine) as a result of each event.
 So we have anywhere from 10 to say 400 global var sets per
 second, and then there are the normal user events (X11 stuff
 like mouse and keyboard activity).

 The global vars in turn are bound via trace to execute
 procs, and by Tk widget bindings to screen updates.
 A typical screen of the GUI might have 20 or 30 "live" data
 items on it (entry boxes, sliders, graphical widgets, plots)
 all updating in near-real-time (modulo the 1Hz binning).  The
 user would usually have only one main screen up at a time,
 but might also pop up as many as 20 subscreens of similar or
 slightly lesser complexity (I have done this).  A typical
 single variable changing state might cause 5 or 6 procedure
 calls to fire off, resulting in actions like logging,
 popping up warnings, changing attributes of canvas objects,
 etc.  In short, there's a whole lot going on all the time :-)

 When I started this project a few years ago, there were one
 or two nay-sayers (notably a guy who had written interfaces
 for the same backend, in C using the X toolkit libs) who
 insisted that Tcl/Tk was "too slow", that "no interpreting
 language could handle realtime interrupts," etc.  These folks
 predicted gloomily that as soon as the live data item count
 reached 100 or so, the app would bog down and die.

 This has never yet happened.  We have seen some bizarre effects
 from long-line latency (5000 mile IP round trips, for example)
 where the Tk event loop seems to get a bit confused, but when
 not working with pathological packet timings, the Tk-based UIs have
 never been distinguishable in performance from C-based UIs.
 They seem fast and responsive to the end-user, which is our
 measure of success.

 In our limited experience, the biggest overhead of a Tk or Tcl
 interp is process startup, so we do try not to launch interps,
 or any other external process, any more than we can help.  We
 have not found Tcl/Tk interps to be big memory leakers, unless
 a badly-written extension has been loaded :-)

 By limiting process startups and following some simple syntactical
 conventions (for example, I believe my crude tests have shown that

     if {$x} { foo }

 is actually faster than

     if $x { foo }

 at least since the bytecode compiler -- correct me, wiser heads,
 if I am wrong about this) we have been very well satisfied with the
 perceived performance of realtime Tcl/Tk applications.

 As to nonGUI scripts, I have even done very small image processing in
 Tcl (using interpreted Tcl for the math as well as the I/O) and
 have not found the speed unacceptable.   Since ds9 (image reduction
 tool) is based on a special Tk widget, it is trivial to extend its
 functionality; therefore I wrote a quick stats box (peak finder,
 eccentricity, sigma) in Tcl/Tk, using FITStcl to reach into a
 FITS format image file for the actual bits;  the rest was simple:
 stuff them into arrays, and do basic expr math to get the answers.
 The perceived speed of this stats box is not significantly different
 from that of a C-based version used with a different imtool.

 You notice I keep saying *perceived* speed, and I think this
 is important.  I mostly write tools for interactive use, so the
 only speed that matters is the speed of response to the user.
 If the user spends time waiting for the tool to respond, it
 is unacceptable;  if the tool can keep up with the fastest
 user's mouse and keyboard activity, then it is acceptable.
 This has very little to do with real performance as measured
 in mflops and mips.

 There are certain problems which are simply better solved with
 C or with a dedicated tool like an RDBMS.  I would not sit down
 to write my own FFT in pure Tcl;  I would not try to write a
 pure-Tcl database manager, but would use a real RDBMS.  And I would
 resort to awk for quickly munging a multi-million-line text file.
 I have never found anything faster than awk for this sort of thing.

 But for ordinary bread-n-butter apps I have no complaints about Tcl
 performance.  Cheaply available CPU power, memory, and fast disk have
 long since caught up with any slowness in interpreting languages, imho.

 Apologies for my verbosity.  I find this question of performance
 (what it really means in different projects) a very interesting one,
 & have never been impressed with published benchmarks. IMHO these
 tell one nothing about the actual deployed performance of most
 languages.  Deployed performance has a lot more to do with things
 like time-to-delivery, time-to-debug, robustness, etc., at least
 in my world... back when we worked on 68000's 6502's and the
 early VAX chips, every mip counted and we coded some parts in
 assembler to squeeze more performance out of the app.  Nowadays
 this seems like ancient history, and the advantages of interpreting
 languages seem to outweigh their overhead.

 I'd be interested to know what others think and how Tcl/Tk
 "performs" in various senses of the word, in your apps.

 de

 --
 .............................................................................
 :De Clarke, Software Engineer                     UCO/Lick Observatory, UCSC:
 :Mail: de@ucolick.org |                                                     :
 :Web: www.ucolick.org |             Don't Fear the Penguins                 :
 --
 .............................................................................
 :De Clarke, Software Engineer                     UCO/Lick Observatory, UCSC:
 :Mail: de@ucolick.org |                                                     :
 :Web: www.ucolick.org |             Don't Fear the Penguins                 :