Version 0 of Memory Footprint Comparisons

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                  7063
    as shipped /w SuSE 6.3
  * python1.5 wish.py tk8.0.5                     4584
    -> demo/widget/floorplan
  * python2.0 wish.py tk8.4a2                     3860
    -> 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 ALLWAYS 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

  Mesa-3.4-SDL-1.1.7                            2044
  SDLgears-1.0.2.tar.gz from  
  http://www.libsdl.org/opengl/

  qt-2.2.1-Mesa-3.4                             5392
  (/usr/local/qt-2.2.1/examples/gear) 

  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

  APPLICATION                                   Memory in KB

  vtk /w Tcl/Tk 8.0.5 SuSE6.3                   16876   after start
  (OO and c++)

  gracer0.1.5  /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                  4380    after start
  img1.2.4,tkhtml ....

  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         10924

  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)                4624

MY RESULTS:

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