Performance problems from 8.0 to 8.2
Kurt Sierens
to upgrade this to 8.2, we are seeing a 2x to 3x slow down.
Does anyone know the specific reasons for the performance decrease?
We haven't run the tests against the 8.3 release, does anyone know what
decrease I should expect between 8.2 and 8.3?
Thanks in advance.
Laurent Duperval
> We have some legacy programs that are still using version 8.0. When we
> went to upgrade this to 8.2, we are seeing a 2x to 3x slow down.
>
> Does anyone know the specific reasons for the performance decrease?
>
No, depends on your code. But you can try the tips at
http://mini.net/tcl/348.html.
L
--
Laurent Duperval <mailto:ldup...@microcelli5.com>
Windows 3.1: The 8MB patch.
Don Porter
> We have some legacy programs that are still using version 8.0. When we went
> to upgrade this to 8.2, we are seeing a 2x to 3x slow down.
Do you know what parts of the code are showing a slow down? What
commands are involved?
> Does anyone know the specific reasons for the performance decrease?
Between 8.0 and 8.2, a number of things happened. Unicode was
introduced, which could slow down string processing; threading
support was introduced, which, if enabled, could slow down just
about everything. There were also changes in byte-code compiling
strategy with impact that's not simple to predict.
> We haven't run the tests against the 8.3 release, does anyone know what
> decrease I should expect between 8.2 and 8.3?
If you've already moved to 8.2, it is nearly certainly [*]
unambiguously to your advantage to upgrade to Tcl 8.3.4. It is
the best Tcl available today that is "stable". If your code works
with Tcl 8.2.x it will work with 8.3.4.
[*] Only possible exception I can think of are some changes to the
Tk C APIs that require a new #define here and there.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Donal K. Fellows
> We have some legacy programs that are still using version 8.0. When we went
> to upgrade this to 8.2, we are seeing a 2x to 3x slow down.
>
> Does anyone know the specific reasons for the performance decrease?
$10 says its because of UNICODE support. :^)
At a guess, you're doing lots of handling of files whose content can be
guaranteed to be single bytes? Have you tried setting the -translation
option (with [fconfigure]) for those channels to "binary"?
> We haven't run the tests against the 8.3 release, does anyone know what
> decrease I should expect between 8.2 and 8.3?
Performance should improve from any 8.2 series interpreter to any 8.3
series interpreter (except in some edge cases which I can't think of right
now) and there are a number of extra things you can do in 8.3 that gain
extra performance. 8.4 (still in alpha) should be faster still, but IMHO
you'd be quite right to avoid alpha code. Even though Tcl's alphas are
typically better than most software's patch releases...
Donal.
--
[Seen in a discussion about automounters; names omitted to protect the guilty]
A> "I don't know. All I know is that it wasn't there until I tried to use it"
B> "You mean like some guy's cat?"
A> "I didn't mount his cat. The photo's are fake"
Kurt Sierens
"Don Porter" <d...@email.nist.gov> wrote in message
news:slrna3jdr...@clover.cam.nist.gov...
> Kurt Sierens wrote:
> > We have some legacy programs that are still using version 8.0. When we
went
> > to upgrade this to 8.2, we are seeing a 2x to 3x slow down.
>
> Do you know what parts of the code are showing a slow down? What
> commands are involved?
Using 'set' is twice as slow, 'expr' calls are 3 times slower, 'foreach'
calls are 3 times slower, '==' tests are twice as slow.
>
> > Does anyone know the specific reasons for the performance decrease?
>
> Between 8.0 and 8.2, a number of things happened. Unicode was
> introduced, which could slow down string processing; threading
> support was introduced, which, if enabled, could slow down just
> about everything. There were also changes in byte-code compiling
> strategy with impact that's not simple to predict.
>
Our applications are threaded ( -MD ) and so the tcl libs were built the
same. What is needed to disable the Tcl threading?
> > We haven't run the tests against the 8.3 release, does anyone know what
> > decrease I should expect between 8.2 and 8.3?
>
> If you've already moved to 8.2, it is nearly certainly [*]
> unambiguously to your advantage to upgrade to Tcl 8.3.4. It is
> the best Tcl available today that is "stable". If your code works
> with Tcl 8.2.x it will work with 8.3.4.
>
We are planning on moving to the latest stable version, probably 8.3.4,
before our next release.
Kurt Sierens
You mentioned that there is "a number of extra things you can do in 8.3 that
gain extra performance" in 8.3. Are these documented somewhere?
"Donal K. Fellows" <fell...@cs.man.ac.uk> wrote in message
news:3C39B903...@cs.man.ac.uk...
Donal K. Fellows
> "Don Porter" <d...@email.nist.gov> wrote:
>> Do you know what parts of the code are showing a slow down? What
>> commands are involved?
>
> Using 'set' is twice as slow, 'expr' calls are 3 times slower, 'foreach'
> calls are 3 times slower, '==' tests are twice as slow.
How are you conducting those tests? Only procedure bodies get the full
benefit of Tcl's bytecode compiler, which can make performance testing
somewhat tricky (but has very good results in most other programs.)
If your program is not using procedures, it might be a very good idea
to change that. We do a lot more to compile procs than we used to.
> Our applications are threaded ( -MD ) and so the tcl libs were built the
> same. What is needed to disable the Tcl threading?
Pass the right option (--disable-threads IIRC) to configure on UNIX.
(I know nothing about building on other platforms, sorry.)
Donal.
-- Fools have been claiming the death of Unix since it was developed in the
late 60's. Unfortunately (for them) the death of Unix keeps getting
postponed, due to circumstances beyond their control.
-- Terry Porter <tjpo...@gronk.porter.net>
Donal K. Fellows
> You mentioned that there is "a number of extra things you can do in 8.3 that
> gain extra performance" in 8.3. Are these documented somewhere?
On the Wiki, URL http://purl.org/thecliff/tcl/wiki/TclPerformance IIRC
lvi...@yahoo.com
According to Kurt Sierens <ku...@altair.com>:
: I have
:also attached the performance testing script that we are using, which can be
:run from wish.
When I run the attached script using wish 8.0, I get this error:
Performing string equality tests ...
Error in startup script: bad option "equal": must be compare, first, index, last, length, match, range, tolower, toupper, trim, trimleft, trimright, wordend, or wordstart
while executing
"string equal "one" "two" "
(procedure "strCmpTest" line 3)
invoked from within
"strCmpTest"
invoked from within
"time strCmpTest $iterations "
(procedure "DoTest" line 73)
invoked from within
"DoTest"
(file "perftest.tcl" line 289)
(P.S. wouldn't using tclsh work just as well?)
Also, turns out there is a known tcl bug (#458361) that results in some of
the timing difference - one Tcl expert writes:
miguel The scriptis timing single-word scripts; the calling sequence is about
5 times slower
:
:
lvirden what is a single word script - do you mean invoking procs and not
providing arguments?
miguel Larry: for instance
time do-this 5
invokes the script {do-this} five times; it is a single-word script -
it wouldn't be if do-this had an argument.
The workaround is to write
time {do-this } 5
(mind the trailing space!) With this, the differences reduce to almost
nothing (except for uplevel/eval)
There is a patch to fix the above bug which some of the experts say they
will revise and apply today.
--
"I know of vanishingly few people ... who choose to use ksh." "I'm a minority!"
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
Bruce Hartweg
<lvi...@yahoo.com> wrote in message news:a1hta9$nt5$1...@srv38.cas.org...
>
>
> Also, turns out there is a known tcl bug (#458361) that results in some of
> the timing difference - one Tcl expert writes:
>
> miguel The scriptis timing single-word scripts; the calling sequence is about
> 5 times slower
> :
> :
> lvirden what is a single word script - do you mean invoking procs and not
> providing arguments?
>
> miguel Larry: for instance
> time do-this 5
> invokes the script {do-this} five times; it is a single-word script -
> it wouldn't be if do-this had an argument.
> The workaround is to write
> time {do-this } 5
> (mind the trailing space!) With this, the differences reduce to almost
> nothing (except for uplevel/eval)
>
Just an FYI - changing the script to do this (NOT changing the test code itself - just the calls
to time them) produces the following (duplicated lines: first line from [time something $iter] 2nd from [time {something } $iter])
This is 8.3.4 on a PIII Win2K box
Performing timing tests using 10000 iterations ...
Performing variable assignment tests ...
uplevel w/level: 37 microseconds per iteration
uplevel w/level: 21 microseconds per iteration
uplevel: 36 microseconds per iteration
uplevel: 18 microseconds per iteration
upvar: 24 microseconds per iteration
upvar: 8 microseconds per iteration
global: 23 microseconds per iteration
global: 8 microseconds per iteration
global namespace: 21 microseconds per iteration
global namespace: 6 microseconds per iteration
local: 19 microseconds per iteration
local: 4 microseconds per iteration
Performing expr tests ( bytecode compiler ) ...
wo/braces: 45
w/braces: 22
difference: 2.05x
wo/braces: 29
w/braces: 6
difference: 4.83x
Performing expr/incr tests ...
expr: 24
incr: 6
difference: 4.00x
Performing eval tests ...
eval wo/list: 35
eval wo/list: 20
eval w/list: 31
eval w/list: 14
eval w/subst: 40
eval w/subst: 23
Performing variable initialization tests ...
inline: 80000
proc based: 60000
Performing list parsing tests ...
for/lindex: 102
while/lindex: 70
foreach: 29
difference: 3.52x
for/lindex: 84
while/lindex: 52
foreach: 12
difference: 7.00x
Performing string equality tests ...
==: 19
strcomp: 20
difference: 0.95x
==: 5
strcomp: 5
difference: 1.00x
Performing return tests ...
return: 18
set: 3
difference: 6.00x
return: 4
set: 3
difference: 1.33x
Performing sum tests ...
sum: 353
fasterSum: 42
difference: 8.40x
sum: 337
fasterSum: 26
difference: 12.96x
Bruce
miguel sofer
> There is a patch to fix the above bug which some of the experts say they
> will revise and apply today.
Bad news from the "expert" (that would be me, I guess): the approach in
my patch introduces a bug that would be triggered by command names with
spaces.
Correct and slow is better than wrong and fast, so it's back to the
drawing board ...
In the meantime, use the workaround described previously: if you have a
script that consists of a single command name and needs to be evaluated
repeatedly, do differentiate "script" and "command name" by adding an
extra space to the script. Note that "script" is something that will be
parsed and evaluated: the body of [if], [while], [foreach], [time],
[catch], ...
OTOH, the bug is likely to show up mostly with [time] if you put most of
your code within procs: if, while, foreach, catch are all bytecompiled
then, and the bug does not show up.
Cheers, sorry
Miguel Sofer