[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 <<br>> as shipped /w SuSE 6.3 | 7063 |&
&| python1.5 wish.py tk8.0.5 <<br>> -> demo/widget/floorplan  | 4584 |&
&| python2.0 wish.py tk8.4a2 <<br>> -> demo/widget/floorplan <<br>> only [tkinter] compiled in w/o "-g" | 3860 |&

''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

  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''

----
!!!!!!
%| [Category Object Orientation] |%
!!!!!!