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 161. 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 | 7063 |
| python1.5 wish.py tk8.0.5 -> demo/widget/floorplan | 4584 |
| python2.0 wish.py tk8.4a2 -> demo/widget/floorplan only tkinter compiled in w/o "-g" | 3860 |
- "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
| APPLICATION "gears" | memory in KB |
|---|---|
| Mesa-3.4-glut3.7 | 2626 |
| Mesa-3.4-SDL-1.1.7 SDLgears-1.0.2.tar.gz from http://www.libsdl.org/opengl/  | 2044 |
| qt-2.2.1-Mesa-3.4 (/usr/local/qt-2.2.1/examples/gear) | 5392 |
| Tcl/Tk8.4a2/frustum0.1-Mesa-3.4 | 4400 |
- 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"
| APPLICATION | Memory in KB |
|---|---|
| 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 | 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 |
- 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 ???
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.
