Hi, some (unproven) statistics from my SW regarding the performance TCL versa PYTHON

The --send ... send packages
The --parent/child ... measure startup time
The other ... build data structures

Tcl is except --parent (startup) slower than python → I think the CORE problem is the OO implementation in TCL

→ the basic technology for TCL and PYTHON is a OO wrapper around the C-library this mean the BASIC workload
for TCL & PYTHON is the same and the TIME difference is just the TCL/PYTHON overload

TCL
===

setup=release
> feature=tcl_pipe
> .../release/inst/sbin/x86_64-suse-linux-gnu-perfclient --timeout 2 --all @ $TCLSH
..../release/inst/sbin/x86_64-suse-linux-gnu-perfserver-tcl.tcl
:PerfClientExec }: start ------------------------ : result [ count / sec ]
:statistics }: --send : 216004.5 [ 432206 / 2.000912 ]
:statistics }: --send-string : 224700.4 [ 449614 / 2.000949 ]
:statistics }: --send-and-callback : 121014.5 [ 242218 / 2.001561 ]
:statistics }: --send-and-wait : 58694.0 [ 117389 / 2.000015 ]
:statistics }: --send-persistent : 13358.7 [ 26718 / 2.000046 ]
:statistics }: --parent : 82.5 [ 165 / 2.000311 ]
:statistics }: --child : 21321.3 [ 42643 / 2.000022 ]
:statistics }: --bus : 40133.7 [ 80268 / 2.000017 ]
:statistics }: --bfl : 41333.4 [ 82667 / 2.000005 ]
:statistics }: --bin : 264818.7 [ 529687 / 2.000187 ]
:statistics }: --str : 265383.5 [ 530867 / 2.000377 ]
:PerfClientExec }: end: ----------------------------------------

PYTHON
======

setup=release
> feature=py_pipe
> .../release/inst/sbin/x86_64-suse-linux-gnu-perfclient --timeout 2 --all @ $PYTHON
..../release/inst/sbin/x86_64-suse-linux-gnu-perfserver-py.py
:PerfClientExec }: start ------------------------ : result [ count / sec ]
:statistics }: --send : 292415.7 [ 584872 / 2.000139 ]
:statistics }: --send-string : 294627.4 [ 589494 / 2.000812 ]
:statistics }: --send-and-callback : 154291.6 [ 308617 / 2.000219 ]
:statistics }: --send-and-wait : 73577.8 [ 147156 / 2.000005 ]
:statistics }: --send-persistent : 13796.6 [ 27594 / 2.000058 ]
:statistics }: --parent : 71.0 [ 142 / 2.000464 ]
:statistics }: --child : 21959.2 [ 43919 / 2.000024 ]
:statistics }: --bus : 67991.3 [ 135983 / 2.000005 ]
:statistics }: --bfl : 65537.4 [ 131075 / 2.000004 ]
:statistics }: --bin : 326737.6 [ 653632 / 2.000480 ]
:statistics }: --str : 327746.7 [ 655625 / 2.000402 ]
:PerfClientExec }: end: ----------------------------------------

This is the reference in C only
===============================

setup=release
> feature=c_pipe
> .../release/inst/sbin/x86_64-suse-linux-gnu-perfclient --timeout 2 --all @
..../release/inst/sbin/x86_64-suse-linux-gnu-perfserver-c
:PerfClientExec }: start ------------------------ : result [ count / sec ]
:statistics }: --send : 372049.5 [ 744214 / 2.000309 ]
:statistics }: --send-string : 388248.2 [ 776648 / 2.000390 ]
:statistics }: --send-and-callback : 221224.1 [ 442541 / 2.000420 ]
:statistics }: --send-and-wait : 87320.3 [ 174641 / 2.000004 ]
:statistics }: --send-persistent : 15245.3 [ 30491 / 2.000024 ]
:statistics }: --parent : 552.4 [ 1105 / 2.000235 ]
:statistics }: --child : 35888.9 [ 71778 / 2.000004 ]
:statistics }: --bus : 80124.6 [ 160250 / 2.000011 ]
:statistics }: --bfl : 86655.9 [ 173312 / 2.000003 ]
:statistics }: --bin : 400718.2 [ 801590 / 2.000383 ]
:statistics }: --str : 396122.8 [ 792369 / 2.000312 ]
:PerfClientExec }: end: ----------------------------------------

On 8/13/24 22:40, aotto1968 wrote:

> Hi, some (unproven) statistics from my SW regarding the performance TCL
^^^^^^^^

Exactly. I tend to go even further and add the attribute useless to
unproven as long as you publish some numbers with some subjective
analysis without presenting the implementation and the measurement
method.

On 13.08.24 22:51, undroidwish wrote:
> On 8/13/24 22:40, aotto1968 wrote:
>
>> Hi, some (unproven) statistics from my SW regarding the performance TCL
>             ^^^^^^^^
>
> Exactly. I tend to go even further and add the attribute useless to
> unproven as long as you publish some numbers with some subjective
> analysis without presenting the implementation and the measurement
> method.

not really, with "aggressive" optimization the TCL is doing better, but not close to PYTHON

setup=release
> feature=cc_pipe
> .../release/inst/sbin/x86_64-suse-linux-gnu-perfclient --timeout 2 --send @
..../release/inst/sbin/x86_64-suse-linux-gnu-perfserver-cc
: start ------------------------ : result [ count / sec ]
: --send : 387331.8 [ 774702 / 2.000099 ]
: end: ----------------------------------------
> feature=c_pipe
> .../release/inst/sbin/x86_64-suse-linux-gnu-perfclient --timeout 2 --send @
..../release/inst/sbin/x86_64-suse-linux-gnu-perfserver-c
: start ------------------------ : result [ count / sec ]
: --send : 390295.8 [ 780623 / 2.000081 ]
: end: ----------------------------------------
> feature=py_pipe
> .../release/inst/sbin/x86_64-suse-linux-gnu-perfclient --timeout 2 --send @ $PYTHON
..../release/inst/sbin/x86_64-suse-linux-gnu-perfserver-py.py
: start ------------------------ : result [ count / sec ]
: --send : 284371.7 [ 568775 / 2.000111 ]
: end: ----------------------------------------
> feature=tcl_pipe
> .../release/inst/sbin/x86_64-suse-linux-gnu-perfclient --timeout 2 --send @ $TCLSH
..../release/inst/sbin/x86_64-suse-linux-gnu-perfserver-tcl.tcl
: start ------------------------ : result [ count / sec ]
: --send : 215990.2 [ 432027 / 2.000216 ]
: end: ----------------------------------------

setup=aggressive
> feature=cc_pipe
> .../aggressive/inst/sbin/x86_64-suse-linux-gnu-perfclient --timeout 2 --send @
..../aggressive/inst/sbin/x86_64-suse-linux-gnu-perfserver-cc
: start ------------------------ : result [ count / sec ]
: --send : 398688.2 [ 797433 / 2.000142 ]
: end: ----------------------------------------
> feature=c_pipe
> .../aggressive/inst/sbin/x86_64-suse-linux-gnu-perfclient --timeout 2 --send @
..../aggressive/inst/sbin/x86_64-suse-linux-gnu-perfserver-c
: start ------------------------ : result [ count / sec ]
: --send : 401113.0 [ 802377 / 2.000376 ]
: end: ----------------------------------------
> feature=py_pipe
> .../aggressive/inst/sbin/x86_64-suse-linux-gnu-perfclient --timeout 2 --send @ $PYTHON
..../aggressive/inst/sbin/x86_64-suse-linux-gnu-perfserver-py.py
: start ------------------------ : result [ count / sec ]
: --send : 286609.9 [ 573378 / 2.000552 ]
: end: ----------------------------------------
> feature=tcl_pipe
> .../aggressive/inst/sbin/x86_64-suse-linux-gnu-perfclient --timeout 2 --send @ $TCLSH
..../aggressive/inst/sbin/x86_64-suse-linux-gnu-perfserver-tcl.tcl
: start ------------------------ : result [ count / sec ]
: --send : 237457.9 [ 475001 / 2.000359 ]
: end: ----------------------------------------

the first analyses is quite simple:

right now python does NOT support threads in NHI1 (will change soon) and tcl does…
this has an influence on the "release" build because this is NHI1 without threads in python and with
threads in tcl.

→ the difference is that the thread-local-storage is an STATIC REFERENCE in python and a POINTER in tcl.

→ the "aggressive" build does NOT use threads at all and the change between python and tcl is more compare-able
but is still ~20%

On 8/14/24 04:16, aotto1968 wrote:
> the first analyses is quite simple:
>
> right now python does NOT support threads in NHI1 (will change soon) and
> tcl does…
> this has an influence on the "release" build because this is NHI1
> without threads in python and with
> threads in tcl.
>
> → the difference is that the thread-local-storage is an STATIC REFERENCE
> in python and a POINTER in tcl.
>
> → the "aggressive" build does NOT use threads at all and the change
> between python and tcl is more compare-able
> but is still ~20%
>

I think the point that androwish was making, without seeing the code we
can not tell if you did something in a way that takes more time than
doing it in a slightly different way.

On 14.08.24 14:04, Gerald Lester wrote:
> On 8/14/24 04:16, aotto1968 wrote:
>> the first analyses is quite simple:
>>
>> right now python does NOT support threads in NHI1 (will change soon) and tcl does…
>> this has an influence on the "release" build because this is NHI1 without threads in python and with
>> threads in tcl.
>>
>> → the difference is that the thread-local-storage is an STATIC REFERENCE in python and a POINTER in tcl.
>>
>> → the "aggressive" build does NOT use threads at all and the change between python and tcl is more compare-able
>> but is still ~20%
>>
>
> I think the point that androwish was making, without seeing the code we can not tell if you did something in a way that takes
> more time than doing it in a slightly different way.

I use the kcachegrind to debug the performance but there are a lot of "small" points to end-up in the ~20% loss against python.

-> I cannot post a "picture" because the "newsgroup does NOT accept pictures …
-> must of the code is in the TCL-C-Api for example:

Example my "ServiceCall" function: at the end of a service call I use:

if (ret == TCL_OK) {
Tcl_ResetResult(interp);
return MkErrorGetCode_0E();
}

and this simple "Tcl_ResetResult" eat 0,8% of the total performance → this is 75% of my "ServiceCall" performance.

-> not trivial, it seems that the Python people with a lot of “manpower” have already MAXIMIZED the optimization of Python.

If I step in Tcl_ResetResult the highlight is:

% eat Total performance -> function name
1,09% -> ResetObjectResult
0,54% -> FreeByteArrayInternalRep (this object is variable size around ~ 1000 bytes)

mfg ao

On 13/08/2024 21:51, undroidwish wrote:
> On 8/13/24 22:40, aotto1968 wrote:
>
>> Hi, some (unproven) statistics from my SW regarding the performance TCL
>             ^^^^^^^^
>
> Exactly. I tend to go even further and add the attribute useless to
> unproven as long as you publish some numbers with some subjective
> analysis without presenting the implementation and the measurement
> method.
+1

On 8/15/24 08:30, Alan Grunwald wrote:
> On 13/08/2024 21:51, undroidwish wrote:
>> On 8/13/24 22:40, aotto1968 wrote:
>>
>>> Hi, some (unproven) statistics from my SW regarding the performance TCL
>>              ^^^^^^^^
>>
>> Exactly. I tend to go even further and add the attribute useless to
>> unproven as long as you publish some numbers with some subjective
>> analysis without presenting the implementation and the measurement
>> method.
> +1
+2

To be more precise I add an image to show the differences TCL versa PYTHON on an the example wrapper function

-> ReadI8

This is from the debugging environment with tcl/py & extension compiled in debug mode.

https://i.postimg.cc/NjXccdRC/performance-check-tcl-versa-python.png

On 15.08.24 20:27, aotto1968 wrote:
>
> To be more precise I add an image to show the differences TCL versa PYTHON on an the example wrapper function
>
> -> ReadI8
>
> This is from the debugging environment with tcl/py & extension compiled in debug mode.
>
> https://i.postimg.cc/NjXccdRC/performance-check-tcl-versa-python.png
>
>

better link → with callgraph
https://i.postimg.cc/TYbNKXrn/performance-check-tcl-versa-python.png

On 15.08.24 20:43, aotto1968 wrote:
> On 15.08.24 20:27, aotto1968 wrote:
>>
>> To be more precise I add an image to show the differences TCL versa PYTHON on an the example wrapper function
>>
>> -> ReadI8
>>
>> This is from the debugging environment with tcl/py & extension compiled in debug mode.
>>
>> https://i.postimg.cc/NjXccdRC/performance-check-tcl-versa-python.png
>>
>>
>
> better link → with callgraph
> https://i.postimg.cc/TYbNKXrn/performance-check-tcl-versa-python.png

even better resolution: https://i.postimg.cc/wvpJV4QC/performance-check-tcl-versa-python.png

On 15.08.24 21:09, aotto1968 wrote:
> On 15.08.24 20:43, aotto1968 wrote:
>> On 15.08.24 20:27, aotto1968 wrote:
>>>
>>> To be more precise I add an image to show the differences TCL versa PYTHON on an the example wrapper function
>>>
>>> -> ReadI8
>>>
>>> This is from the debugging environment with tcl/py & extension compiled in debug mode.
>>>
>>> https://i.postimg.cc/NjXccdRC/performance-check-tcl-versa-python.png
>>>
>>>
>>
>> better link → with callgraph
>> https://i.postimg.cc/TYbNKXrn/performance-check-tcl-versa-python.png
>
> even better resolution: https://i.postimg.cc/wvpJV4QC/performance-check-tcl-versa-python.png

bad that I can not EDIT old data of this news message… the problem is that the "postimage" stuff
changes the resolution of the image → bad

I switch to the good old Facebook to post this screenshot and wait for your comment.

-> https://www.facebook.com/share/p/wihmQPR4pBRacLLF/

a short conclusion from Facebook …

"If you analyze the C lib wrapper for MqReadI8, the TCL code adds about 200% wrapper load and the PYTHON code adds about 10%
wrapper load." (ref: https://www.facebook.com/share/p/wihmQPR4pBRacLLF/)

→ I think TCL has an "performance-problem".

On 8/15/2024 3:09 PM, aotto1968 wrote:
>
> even better resolution:
> https://i.postimg.cc/wvpJV4QC/performance-check-tcl-versa-python.png

Very nice screenshots. Is this some sort a debugger?

Assuming that you wrote both tcl and python versions and that they both
wrap the same core library, wouldn't the call trees look the same or at
least bear resemblance?

On 16.08.24 01:39, saito wrote:
> On 8/15/2024 3:09 PM, aotto1968 wrote:
>>
>> even better resolution: https://i.postimg.cc/wvpJV4QC/performance-check-tcl-versa-python.png
>
> Very nice screenshots. Is this some sort a debugger?
>
> Assuming that you wrote both tcl and python versions and that they both wrap the same core library, wouldn't the call trees look
> the same or at least bear resemblance?

Yes, both the TCL and PYTHON extensions are wrappers for the same library and the TOOL for writing both wrappers is the NHI1/ALC
(All-Language-Compiler), that is why both wrappers look similar.

the memory debugger has two parts
1) valgrind --tool=callgrind --quiet ... your sw → create callgrind.out.*
2) kcachegrind callgrind.out.* → create the view

Am 15.08.24 um 23:48 schrieb aotto1968:
> a short conclusion from Facebook …
>
> "If you analyze the C lib wrapper for MqReadI8, the TCL code adds about
> 200% wrapper load and the PYTHON code adds about 10% wrapper load."
> (ref: https://www.facebook.com/share/p/wihmQPR4pBRacLLF/)
>
> → I think TCL has an "performance-problem".

I won't solve the problem, just to say: It's impossible to help you with
this, because you don't explain:
* who wrote this wrapper
* where to find the code
* what benchmark are you running

It could be, e.g. that your benchmark code introduces shimmering and
then there's lots of conversion going on. It might be something
completely different. Or it might be that Tcl is indeed slower than
Python (in most of my comparisons, it was the opposite - unless you
offload work to external libraries).

Regards,

Christian

On 8/16/24 09:12, Christian Gollwitzer wrote:
> Am 15.08.24 um 23:48 schrieb aotto1968:

>> ...
>> → I think TCL has an "performance-problem".
>
> I won't solve the problem, just to say: It's impossible to help you with
> this, because you don't explain:
> * who wrote this wrapper
> * where to find the code
> * what benchmark are you running
> ...

+1

PS: Philosophically, the perpetual perception of performance problems
is inherent to human design (and possibly inextricable even).

On 16.08.24 09:12, Christian Gollwitzer wrote:
> Am 15.08.24 um 23:48 schrieb aotto1968:
>> a short conclusion from Facebook …
>>
>> "If you analyze the C lib wrapper for MqReadI8, the TCL code adds about 200% wrapper load and the PYTHON code adds about 10%
>> wrapper load." (ref: https://www.facebook.com/share/p/wihmQPR4pBRacLLF/)
>>
>> → I think TCL has an "performance-problem".
>
> I won't solve the problem, just to say: It's impossible to help you with this, because you don't explain:
> * who wrote this wrapper
> * where to find the code
> * what benchmark are you running
>
> It could be, e.g. that your benchmark code introduces shimmering and then there's lots of conversion going on. It might be
> something completely different. Or it might be that Tcl is indeed slower than Python (in most of my comparisons, it was the
> opposite - unless you offload work to external libraries).
>
> Regards,
>
>       Christian

1) just the "stupid" Tcl_ObjectGetMetadata to retrieve the pointer associated with an oo-object cost 1/3 of the wrapper
performance → the whole header of a tcl OO wrapper cost more than everything else in the wrapper.

-> if you look into the code it is an hash-table lookup !!!
-> in python it is a ZERO-time operation

2) just to create an INT-object from an integer the TCL create always an object from scratch inclusive malloc etc
-> python uses for small numbers (integer) a table of already pre-alloc objects as ZERO-time operation

3) the set/reset-result have to free all the (stupid) objects that add additional 1/3 of the wrapper cost

analysis.

-> the Tcl_ObjectGetMetadata is clear an design-error
-> the missing small-int-object pre-alloc is an programmer-lazy-error

if someone can setup a screen sharing session than I can explain the problem in more detail
( need to test the screen-sharing first because because I not use to it )

On 8/16/2024 1:34 AM, aotto1968 wrote:
> On 16.08.24 01:39, saito wrote:
>> On 8/15/2024 3:09 PM, aotto1968 wrote:
>>>
>>> even better resolution:
>>> https://i.postimg.cc/wvpJV4QC/performance-check-tcl-versa-python.png
>>
>> Very nice screenshots. Is this some sort a debugger?
>>
>> Assuming that you wrote both tcl and python versions and that they
>> both wrap the same core library, wouldn't the call trees look the same
>> or at least bear resemblance?
>
>
> Yes, both the TCL and PYTHON extensions are wrappers for the same
> library and the TOOL for writing both wrappers is the NHI1/ALC
> (All-Language-Compiler), that is why both wrappers look similar.

What I meant was that the two images look very different. I can't make
out what the boxes say, but nevertheless one is wide and shallow, the
other narrow and deep. So this may not be an apples-to-apples
comparison. As has been noted already, shimmering may play a role here
or extra levels of abstraction via extra proc calls may skew the results
in one language vs. the other.

I spend some time on research and further optimization ... but ...

One thing seems clear: "lang-Python" with AGGRESSIVE optimization is NOT far from "lang-C" speed.
With aggressive optimization, Python creates a runtime optimization (--enable-optimizations) during compilation and that WITH
threads which, unlike TCL, CANNOT be disabled in Python. Also, the runtime library is FIRMLY integrated into Python.

TCL with aggressive optimization also uses the static runtime library BUT no threads.

→ for updates check the picture in the comment. https://www.facebook.com/share/p/WYmfnRWybY1Sh42f/

summary for aggressive …

> .../perf-aggressive/inst/sbin/c/x86_64-suse-linux-gnu-perfclient --timeout 2 --send --sec 4 @
..../perf-aggressive/inst/sbin/c/x86_64-suse-linux-gnu-perfserver
:PerfClientExec }: start ------------------------ : result [ count / sec ]
:statistics }: --send : 403779.6 [ 1615234 / 4.000286 ]
:PerfClientExec }: end: ----------------------------------------

> .../perf-aggressive/inst/sbin/c/x86_64-suse-linux-gnu-perfclient --timeout 2 --send --sec 4 @ $PYTHON
..../perf-aggressive/inst/sbin/py/x86_64-suse-linux-gnu-perfserver.py
:PerfClientExec }: start ------------------------ : result [ count / sec ]
:statistics }: --send : 311506.7 [ 1246216 / 4.000608 ]
:PerfClientExec }: end: ----------------------------------------

> .../perf-aggressive/inst/sbin/c/x86_64-suse-linux-gnu-perfclient --timeout 2 --send --sec 4 @ $TCLSH
..../perf-aggressive/inst/sbin/tcl/x86_64-suse-linux-gnu-perfserver.tcl
:PerfClientExec }: start ------------------------ : result [ count / sec ]
:statistics }: --send : 227151.4 [ 908663 / 4.000253 ]
:PerfClientExec }: end: ----------------------------------------

On 16.08.24 20:29, saito wrote:
> On 8/16/2024 1:34 AM, aotto1968 wrote:
>> On 16.08.24 01:39, saito wrote:
>>> On 8/15/2024 3:09 PM, aotto1968 wrote:
>>>>
>>>> even better resolution: https://i.postimg.cc/wvpJV4QC/performance-check-tcl-versa-python.png
>>>
>>> Very nice screenshots. Is this some sort a debugger?
>>>
>>> Assuming that you wrote both tcl and python versions and that they both wrap the same core library, wouldn't the call trees
>>> look the same or at least bear resemblance?
>>
>>
>> Yes, both the TCL and PYTHON extensions are wrappers for the same library and the TOOL for writing both wrappers is the
>> NHI1/ALC (All-Language-Compiler), that is why both wrappers look similar.
>
>
> What I meant was that the two images look very different. I can't make out what the boxes say, but nevertheless one is wide and
> shallow, the other narrow and deep. So this may not be an apples-to-apples comparison. As has been noted already, shimmering may
> play a role here or extra levels of abstraction via extra proc calls may skew the results in one language vs. the other.
>
>

these two pictures are generated by the tool and not by me…
-> the TCL picture is so "wide" because the TCL uses a lot of "overhead"
-> the python picture is so "narrow" because PYTHON uses much less "overhead".

On 8/16/24 22:19, aotto1968 wrote:

> ...
> these two pictures are generated by the tool and not by me…
> -> the TCL picture is so "wide" because the TCL uses a lot of "overhead"
> -> the python picture is so "narrow" because PYTHON uses much less
> "overhead".

Hmm, so here we are:

a) you complain about Tcl's bad performance
b) you seem to be unwilling to disclose enough information about the
Python and Tcl implementations in order to get the big picture and
see the cause of differences and to try to discuss improvements
with you
c) due to b) you continue to complain about Tcl's bad performance

Not quite a fruitful cycle.

On 17.08.24 06:27, undroidwish wrote:
> On 8/16/24 22:19, aotto1968 wrote:
>
>> ...
>> these two pictures are generated by the tool and not by me…
>> -> the TCL picture is so "wide" because the TCL uses a lot of "overhead"
>> -> the python picture is so "narrow" because PYTHON uses much less "overhead".
>
> Hmm, so here we are:
>
> a) you complain about Tcl's bad performance
> b) you seem to be unwilling to disclose enough information about the
>    Python and Tcl implementations in order to get the big picture and
>    see the cause of differences and to try to discuss improvements
>    with you
> c) due to b) you continue to complain about Tcl's bad performance
>
> Not quite a fruitful cycle.
>
>
I'm "not" complain about TCL bad performance I just mention that PYTHON has
done much more work on performance than TCL.

If you have 300.000 transaction per second (PYTHON) or 200.000 transaction
per second (TCL) is just an case for someone who need this difference.

On 8/17/24 07:28, aotto1968 wrote:

> ...
> I'm "not" complain about TCL bad performance I just mention that PYTHON has
> done much more work on performance than TCL.

Fine, then please elaborate on this claim. What exactly did Python
better and more in terms of performance? Any pointers welcome.

> If you have 300.000 transaction per second (PYTHON) or 200.000 transaction
> per second (TCL) is just an case for someone who need this difference.

Indeed could this be a reason to ask if there are better ways of using
the Tcl framework in order to get the Tcl implementation be on par with
the Python one. As stated many times before, to discuss this on c.l.t.
will require that you provide more implementation details.

add some documentation regarding the performance testing:
-> http://thedev.nhi1.de/theLink/main/md_docs_2main_2README__PERFORMANCE.htm