Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Why Tcl_Eval runs slower in 8.6 than 8.5?

104 views
Skip to first unread message

wren...@gmail.com

unread,
Nov 7, 2017, 1:09:06 AM11/7/17
to
I have an application using Tcl interp as embeded parser for the functionality.

The new app built with Tcl8.6.3(TCLALLOC mode, threaded and shared) uses TCL_EVAL() which runs 20% slower than the old app built with Tcl8.5.10(TCLALLOC mode, threaded, shared).

According to https://wiki.tcl.tk/1611, it said tcl_eval() had regression on performance. Is it true? if true, any plan to kill this regression?

Tao

Christian Gollwitzer

unread,
Nov 7, 2017, 1:27:47 AM11/7/17
to
Am 07.11.17 um 07:09 schrieb wren...@gmail.com:
> I have an application using Tcl interp as embeded parser for the functionality.
>
> The new app built with Tcl8.6.3(TCLALLOC mode, threaded and shared) uses TCL_EVAL() which runs 20% slower than the old app built with Tcl8.5.10(TCLALLOC mode, threaded, shared).
>

Is there any reason that you don't use the newest version, 8.6.7 ? Tcl's
versioning numbers are deceptive, there are HUGE improvements in between
those "minor" versions and several years of development.

> According to https://wiki.tcl.tk/1611, it said tcl_eval() had regression on performance. Is it true? if true, any plan to kill this regression?

That comparison is also extremely old. The version of 8.6 there was a
beta before 8.6.0. There has been a fundamental change between 8.5 and
8.6, namely stackless execution, which enables coroutines etc., so maybe
it IS slower, but please measure using th emost current version.

And: Are you using Tcl_Eval to run individual statements? The Tcl
developers only care about the speed of the bytecode, i.e you must put
your code in a proc and run it to get the fastest execution.

Christian

wren...@gmail.com

unread,
Nov 7, 2017, 3:38:30 AM11/7/17
to
Thanks Crhistian for your prompt reply.

The version I used just because when app version is confirmed that Tcl has that version offered. I do have script in proc for bytecode optimization. While the testing showed 8.6 slower .

Tao

Gerald Lester

unread,
Nov 7, 2017, 9:10:40 AM11/7/17
to
On 11/07/2017 02:38 AM, wren...@gmail.com wrote:
> On Tuesday, November 7, 2017 at 2:27:47 PM UTC+8, Christian Gollwitzer wrote:
>> Am 07.11.17 um 07:09 schrieb wren...@gmail.com:
>> ...
>> And: Are you using Tcl_Eval to run individual statements? The Tcl
>> developers only care about the speed of the bytecode, i.e you must put
>> your code in a proc and run it to get the fastest execution.
>>
>> Christian
>
> Thanks Crhistian for your prompt reply.
>
> The version I used just because when app version is confirmed that Tcl
> has that version offered. I do have script in proc for bytecode
> optimization. While the testing showed 8.6 slower .

I have no idea what your first sentence means.

Also do you have curly braces around the expressions? For instance:
set c [expr {$a + $b}]
instead of:
set c [expr $a + $b]

--
+----------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald...@kng-consulting.net |
+----------------------------------------------------------------------+

Don Porter

unread,
Nov 7, 2017, 10:16:25 AM11/7/17
to
On 11/07/2017 01:09 AM, wren...@gmail.com wrote:
> The new app built with Tcl8.6.3(TCLALLOC mode, threaded and shared) uses TCL_EVAL() which runs 20% slower than the old app built with Tcl8.5.10(TCLALLOC mode, threaded, shared).

Please share the code and measurement recipe you used to determine
this.

Please stop using outdated patch releases. Compare 8.5.19 to 8.6.7.

There's very little that can be done with a general complaint
that some release "is slow". Give us the benchmark script that has
become slower so we have a chance to drill down to what the substantive
issue is.

The smaller and more focused the demonstration the better, and the
more likely someone can and will look into it.

--
| Don Porter Applied and Computational Mathematics Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|

wren...@gmail.com

unread,
Nov 8, 2017, 12:32:15 AM11/8/17
to
Thanks, Don. I knew that "slower" better addressed with test cases/scripts. My app is a message creator and parser where Tcl is used as the embedded interp inside C sources. It's a little bit hard to get benchmark script because it is property.

The fact I saw my app got regression about 20% on performance from Tcl 8.5.12 to 8.6.3. App loads testing file, parses it and manipulates it by Tcl interp.

Yes, thinking of the way narrow down to the cause. And wonder any similar experience in community here.

Donal K. Fellows

unread,
Nov 8, 2017, 3:19:22 AM11/8/17
to
On 07/11/2017 06:09, wren...@gmail.com wrote:
> The new app built with Tcl8.6.3 (TCLALLOC mode, threaded and shared)
> uses TCL_EVAL() which runs 20% slower than the old app built with
> Tcl8.5.10 (TCLALLOC mode, threaded, shared).
There are some aspects of Tcl which most definitely did get slower from
8.5 to 8.6, often with good reasons, but there are other aspects that
got faster. Because of that, it's extremely difficult to make a
statement that could help you without seeing a sample of code that is
problematic; details matter a lot here.

However, that said… Tcl_Eval() itself is not a path that receives heavy
performance optimisation; it literally requires its scripts to be
interpreted from scratch with very little possibility of caching that is
worthwhile. Tcl_EvalObj(), Tcl_EvalObjEx() and Tcl_EvalObjv() are code
paths that admit going quite a bit faster, though at the cost of the API
being a bit different. (Yes, they all evaluate something, but the
details vary critically.)

Donal.
--
Donal Fellows — Tcl user, Tcl maintainer, TIP editor.

Gerald Lester

unread,
Nov 8, 2017, 9:00:43 AM11/8/17
to
HCI's Cloverleaf is a similar app.

Gerald Lester

unread,
Nov 8, 2017, 9:04:12 AM11/8/17
to
On 11/07/2017 11:32 PM, wren...@gmail.com wrote:
> On Tuesday, November 7, 2017 at 11:16:25 PM UTC+8, Don Porter wrote:
>> On 11/07/2017 01:09 AM, wren...@gmail.com wrote:
>>> The new app built with Tcl8.6.3(TCLALLOC mode, threaded and shared) uses TCL_EVAL() which runs 20% slower than the old app built with Tcl8.5.10(TCLALLOC mode, threaded, shared).
>>
>> Please share the code and measurement recipe you used to determine
>> this.
>>
>> Please stop using outdated patch releases. Compare 8.5.19 to 8.6.7.
>>
>> There's very little that can be done with a general complaint
>> that some release "is slow". Give us the benchmark script that has
>> become slower so we have a chance to drill down to what the substantive
>> issue is.
>>
>> The smaller and more focused the demonstration the better, and the
>> more likely someone can and will look into it.
>>
> Thanks, Don. I knew that "slower" better addressed with test cases/scripts. My app is a message creator and parser where Tcl is used as the embedded interp inside C sources. ..,

Donal pointed out in another reply that it matters a lot if you are
using the older string APIs or the newer object APIs -- the object APIs
can be much faster.
0 new messages