Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: aotto1968 <aotto1968@t-online.de>
Newsgroups: comp.lang.tcl
Subject: Re: tcl versa python regarding performance
Date: Fri, 16 Aug 2024 11:44:26 +0200
Organization: A noiseless patient Spider
Lines: 42
Message-ID: <v9n71q$1cu04$1@dont-email.me>
References: <v9ggb7$2dcu$1@dont-email.me> <v9lhb6$123t3$1@dont-email.me>
 <v9lt3n$13q5g$1@dont-email.me> <v9mu5l$1bolj$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 16 Aug 2024 11:44:27 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3624925180c4abfa43b965e00f9f9a60";
	logging-data="1472516"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/xEroAy5APXRvMHts0vTRcgwn/KTqIAfg="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:QRVcQMoNjW5+Bb0XpxVP8SnVyZU=
In-Reply-To: <v9mu5l$1bolj$1@dont-email.me>
Content-Language: en-US
Bytes: 3029

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 )