Actual implementation doesn't put accent on performances. It must be seen as a prototype which must be stretched further. However, measuring the performances of the STK package is a difficult task and has not been really done yet. What we can say for now is that there is a little overhead when calling a Tk primitive written in C since the STK package must translate all the parameters in C strings. This translation must be done because the Tk library ``thinks'' that it works on Tcl which uses strings for passing parameters. In counterpart, procedure written in Scheme are far more efficient than Tcl scripts since the Scheme interpreter uses an appropriate format which is cheaper than strings. In particular, there is no data conversion when other Scheme procedures are called. Using the object extension of STK gives this tool more power but is, as we can expect, more time consuming. For now, penalty when using the STK object oriented layer is mainly due to object creation: creating a widget with a make is nearly 20 times slower than basic creation achieved by using only first level primitives. However, getting or reading a Tk option using a slot access is only 1.5 times slower than direct Tk configuration. We can expect that rewriting some parts of the STK object layer in C will decrease those ratios. Comparing the Tcl and Scheme approaches needs much more working; and a complete study will be done when the package will be more stable.