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|
| perl-5.004/pTK "widget" demo |
as shipped /w SuSE 6.3
| python1.5 wish.py tk8.0.5 |
| python2.0 wish.py tk8.4a2 |
only tkinter compiled in w/o "-g"
- "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-SDL-1.1.7 |
| qt-2.2.1-Mesa-3.4 |
- 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 /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 ???
- 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.