Updated 2007-12-24 15:04:49 by dkf

Andreas Kupries: The following is a mail from Christian Wegehaupt, placed here with his permission. Right now I will just place it into the wiki, formatting and cleaning up the english and style will come later.

Hi Jeff!

There are lot of discussions within CLT on "enhancing" Tcl by Qt, OO-packages w/c++ etc. etc.

All the experts forget a MEMORY FOOTPRINT calculation.

Let's compare...

O.K., I know that the different packages might use different memory allocation strategies etc., but comparing the packages as shipped or compiled by default is, what's the enduser is seeing...

Test system: ATHLON 500, SuSE6.3, Linux_2.2.18, egcs-2.91.66, X -bpp 16

1. Everybody knows Tk's "floorplan" and the "top" command:
APPLICATION "floorplan" memory in KB
wish4.2 ->demo/widget/floorplan 2188
wish8.0.5 ->demo/widget/floorplan 2992
wish8.4a2 ->demo/widget/floorplan 3076
perl-5.004/pTK "widget" demo
as shipped /w SuSE 6.3
python1.5 wish.py tk8.0.5
-> demo/widget/floorplan
python2.0 wish.py tk8.4a2
-> demo/widget/floorplan
only tkinter compiled in w/o "-g"

MY conclusions:

  • "floorplan" can be taken as an GUI to a LOGISTIC- or FACTORY MANAGEMENT application...
  • There's NO speed difference visible
  • wish ALWAYS starts faster
  • in case of memory shortness wish4.2 is sufficient: e.g. Realtime Linux on an 486 16Meg

2. Lets compare Mesa's "gears"

All programs are doing the same OpenGL-calls generating the "gears" while the user interface is different. For comparsion the screen-size is reduced to 300x300. (SDL = Simple DirectMedia Library)
APPLICATION "gears" memory in KB
Mesa-3.4-glut3.7 2626
SDLgears-1.0.2.tar.gz from
Tcl/Tk8.4a2/frustum0.1-Mesa-3.4 4400

MY conclusions:

  • Mesa-3.4-SDL-1.1.7 is about 20% FASTER than Mesa-3.4-glut3.7 !
  • A Tcl/qt-2.2.1 package would require MUCH more memory ignoring QT's problems with the color-managent on 256 color systems.
  • Tcl/Tk8.4a2/frustum0.1-Mesa-3.4 as a "scripting language" offers MUCH MORE than the compiled "competitors"

3. Some other REAL LIFE applications
vtk /w Tcl/Tk 8.0.5 SuSE6.3
(OO and c++)
16876 after start
[gracer]0.1.5[1] /w Tcl/Tk 8.0.5 Mesa-3.4 3572 after start
tkgate1.5p2 /w Tcl/Tk 8.4a2 3452 after start
iwidgets3.0.1/demos/watch Tcl/Tk 8.4a2 3248
hv (Hipps HTML Viewer tkhtml) 2372 after start
BrowseX 1.0.28 /w Tcl/Tk 8.3
img1.2.4, tkhtml ....
4380 after start
BrowseX 1.2.1 /w Tcl/Tk 8.3 5664 after start
netscape 4.7 13224 after start
Tcl/Tk 8.3 application /w BLT,memchan and
a "listbox" loaded /w 86855 lines
voodoo /w Tcl/Tk 8.3 (C++/Tcl application)
after loading a 59-object diagram
(tested on AMD K6-II 400, 128 MB RAM,
Debian woody, g++ 2.95.3)


  • Speed is not all...
  • Apart from differences in "features", Tcl/Tk seems to be always the "best choice".
  • OO in combination with c++ is WASTING resources without any visible advantage...
  • gracer0.1.5 and tkgate1.5p2 for me are CLASSICAL examples how efficient Tcl/Tk can be embedded into an application...
  • Peter MacDonald's BrowseX demonstrates how efficient the EXISTING packages and apps can be combined to an valuable Browser. Works fine on my old 486-16Meg, while compiling qt-2.2.1 on my old 486-16Meg... it's a shame.
  • We should provide available C-written Tk-extensions like Hipp's plot3d- and tkhtml-widget in a similar way like your great TkTable to SourceForge...
  • We should continue optimising Tk's existing widgets...
  • Where are comparable applications written in Perl or Python ???

Happy New Year!

Christian Wegehaupt

Other notes:

  • Using C++ for what it's good at (efficient, memory-compact OO) and Tcl for what it's good at (high-level view of algorithms, powerful GUI primitives) can yield surprisingly compact results;
  • From my informal tests, however, it is not possible to use the Tk APIs in a really efficient manner from C or C++; the Tk API is too limited for that;
  • C++, used properly, does not waste any memory whatsoever; in fact, it allows very precise control of resources;
  • Tcl/Tk is valuable as a script language, but it's even more so as a part of a hybrid application.

-- BGE