Activity for [incr Tcl]
-
Michał Mrozik created ticket #293
Destructor silently fails to delete class object
-
[incr Tcl] released /[Incr Tcl_Tk]-source/itcl 3.4.4/itcl3.4.4.tar.gz
-
-
-
Szabó László Zoltán created ticket #292
Thread containing an itcl::ensemble crashes by releasing
-
-
Don Porter modified ticket #291
memory leak in ItclCreateArgList function
-
Sure looks like this was fixed more than 2 years ago. Upgrade to fix. https://core.tcl-lang.org/itcl/info/0b0d0e0b8cd8105c
-
That said, the routine ItclCreateArgList() in current development certainly includes ckfree() calls on both argv and defaultArgv. Can you specify the code path that misses those calls and leaks?
-
~~~ All work on Itcl 4.0.* is abandoned. Upgrade to Itcl 4.1.2 or development trunk.
-
Gevorg Tevosyan posted a comment on ticket #291
My Itcl version is 4.0.4
-
memory leak in ItclCreateArgList function
-
Joakim Tjernlund created ticket #54
Please release 4.1.3
-
Tim Tomkinson created ticket #290
Class Procedures Can Be Called Like Methods
-
Composition Access Error
-
itcl::local does not support class names that start with a digit
-
Trey Jackson posted a comment on ticket #271
Related performance issue, using latest Itcl (4.1.1) versus 3.2, a 2.6X slowdown in simple script Itcl 3.2: 4.7 seconds Itcl 4.1.1: 12.2 seconds Script is: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17#!/bin/sh #-*-Tcl-*- the next line restarts using wish \ exec tclsh "$0" "$@" puts "Itcl version: [package require Itcl]" itcl::class myclass { public method member_function {} {} public method call_member_function {ntimes} { for {set i 0} {$i < $ntimes} {incr i} { member_function } } } myclass myobj puts...
-
itcl::scope and itcl::configbody interaction: can't scope variable: missing object context
-
Recursive method memory leak
-
Once I set up a testbed with all those outdated releases on an OSX High Sierra system, my testing shows no failure running the test script. Sorry, but there continues to be nothing I can do when I cannot reproduce the failure.
-
Pan Chai posted a comment on ticket #117
This is still happening. I have more information about this one, Xcode: 9.4+ Mac OSX: Sierra and High Sierra. The test scripts is failing now all the time, once I upgraded Xcode to 9.4.2. Again, I enclosed this script for you.. package require Iwidgets ::iwidgets::radiobox .pref -labeltext "Window Management" .pref add NONE -text "Leave existing windows open when opening new one" .pref add HIDE -text "Hide existing windows when opening new one" .pref add CLOSE -text "Close existing windows when opening...
-
Can I request a new release of Itcl with this patch on it? 4.1.2? We're trying to finish our porting to Tcl 8.6, and this would help us improve our performance tests to come close to 8.4 performance.
-
Duplicate method/proc error message
-
Remove "my" from constructor error message
-
That was huge. Thanks. The time spent in Tcl_Preserve/Tcl_Release is much reduced (from a total of >20 seconds to about 6 seconds). There are no obvious Itcl-related performance issues for this particular usage of my tool. On to the next issue for me!
-
Poor Yorick posted a comment on ticket #271
In commit 7388d7698118df3 ItclMemberCode uses reference counting instead of Itcl_PreserveData.
-
Gladly.
-
When an ItclMemberCode improvement is done, we'll want you to try it and determine how much it helps you.
-
So... did you want something specific from me? I could update the Itcl code to see which calls are actually being taken - along with a counter. Let me know, I can modify things.
-
Looks like the next low-hanging fruit in preserve elimination is ItclMemberCode. Give it a proper refcount as we've done with several other structs now.
-
Sorry, no. At base that implementation also calls Tcl_Preserve.
-
There's a build option in Itcl, ITCL_PRESERVE_DEBUG that makes it use its own implementation instead of a call to Tcl_Preserve. It's possible that will have a different performance impact.
-
~~~~ Ok. It's only in the implementation of Itcl_PreserveData(), but that still gets significant use.
-
~~~~ I see only 3 calls to Tcl_Preserve() left in the Itcl trunk of development. You're really seeing one or more of them account for significant runtime? Please tell more.
-
Side question - in my profiling, the vast majority of the time (between 3.2 and 4.1.1) appears to be in Tcl_Preserve/Tcl_Release, and those appear to be relatively unchanged between Tcl 8.4 and 8.6. Any idea why this might be? Just used more now? Perhaps teh Tcl_MutexLock/Unlock is slower? (I've got a single Tcl interpreter, there might be other threads in the application, but they're not Tcl related....)
-
Object creation local to a proc is 3-4X slower in 4.1.1 vs. 3.2 (don' t have 3.4 numbers) Itcl 3.2 12 microseconds per iteration for 10000 creation of objects in a proc call Itcl 4.1.1 45.0342 microseconds per iteration for 10000 creation of objects in a proc call Note: it's only about 36 microseconds if the SimpleClass is an empty class, ala itcl::class SimpleClass {} But it's instructive that adding a variable and method to a class increases the runtime by ~30% in 4.1.1, whereas in 3.2, the runtime...
-
Understood. Just pointing out areas of potential slowdown. I'll put in a couple more.
-
Confirmed I see factor of 4 slower operation in Itcl 4.1.1 compared with 3.4.4. No idea yet whether there's anything reasonable that can be done about it.
-
I don't think it's a bug, no. I think it's intrustion into an implementation detail. If there's documentation otherwise, let me know.
-
So, where do I file a bug against 3.4.4? It works in 4.1.1, and 3.2, so it seems like a bug, no?
-
ok, I see. "proc: -> "itcl::body" makes it work ok.
-
Indeed these test scripts do not run in Itcl 3.4.4. That's what I'm willing to test.
-
Fair enough. Here's the singleton example - no code change, works for me with Tcl 8.67 and Itcl 4.1.1 (actually latest fossil version), and in 8.4 3.2 Note: GetSingleton is defined using [proc], which has always worked for us (Itcl 3.2 or 4.1) - but it does have problems with Itcl 3.4. It's fixed by changing that to [itcl::body]. Perhaps that's the issue you saw (Itcl 3.4?). Anyway, output first, then script Tcl 8.6.7 Itcl 4.1.1 12.9345 microseconds per iteration per each 10000 class calls that use...
-
Fair enough. Here's the singleton example - no code change, works for me with Tcl 8.67 and Itcl 4.1.1 (actually latest fossil version), and in 8.4 3.2 Note: GetSingleton is defined using [proc], which has always worked for us (Itcl 3.2 or 4.1) - but it does have problems with Itcl 3.4. It's fixed by changing that to [itcl::body]. Perhaps that's the issue you saw (Itcl 3.4?). Anyway, output first, then script Tcl 8.6.7 Itcl 4.1.1 12.9345 microseconds per iteration per each 10000 class calls that use...
-
This is probably related: http://core.tcl.tk/tcl/tktview?name=3610400fff
-
~~~~ This change is due to a re-implementation in terms of [tailcall]. Here's a Tcl-only demonstration: % proc cb args {puts TRACE:$args} % proc demo {} { tailcall string cat x } % trace add execution demo leave cb % demo TRACE:demo 0 {} leave x If execution traces and [tailcall] are not supposed to interact this way, it's a matter to get resolved in Tcl itself.
-
Maybe we can try this with one focused, working example at a time?
-
Demo script doesn't work: invalid command name "GetSingleton" while executing "GetSingleton" (procedure "CWithProc::CallSomeMethod" line 2) invoked from within "CWithProc::CallSomeMethod" invoked from within "time {CWithProc::CallSomeMethod} $count" (procedure "test_calls_to_singleton_via_class_proc" line 2) invoked from within "test_calls_to_singleton_via_class_proc" (file "/home/dgp/sf271.tcl" line 274)
-
I've been tracking down performance issues with Itcl, and while 4.1.1 (and top of trunk) definitely improve things, there are a couple of simple patterns which exhibit degradation from Itcl 3.2 local object creation/deletion in Tcl proc: 4.1.1: 48micros 3.2: 11micros, ratio: ~4:1 call to member method via eval and itcl::code: 4.1.1 4.8micros, 3.2: 1micros, ratio: ~5:1 a simple singleton pattern: 4.1.1 13.7micros, 3.2: 2 micros. ratio: ~7:1 other patterns have about a 30-50% performance penalty Output...
-
Itcl object creation interaction with [trace add execution Class leave]
-
"info vars" fails with no pattern
-
Fix committed to trunk. Will be in Itcl 4.1.2
-
Don't know why it wasn't clear before, but this is a simple fix.
-
$ tclsh % dict get [namespace ensemble configure info -map] vars ::tcl::info::vars % package require Itcl 4.1.1 % dict get [namespace ensemble configure info -map] vars ::itcl::builtin::Info::vars
-
The "dgp-method-type" branch has become the Itcl 4.1.* branch which is now the trunk, so this needs a solution.
-
-
Fixed for Itcl 4.1.2
-
Protected common variables not visible to children
-
Missing object name should generate an error
-
Throwing an error from within an itcl::ensemble causes a segmentation fault (core dump)
-
Fixed for Itcl 4.1.2
-
By all appearances, in the entire Itcl 4 development history, this just hasn't been done. I suspect it's not hard to do, but I'm not ready to predict a completion date. You can keep using Itcl 3.4.4 with Tcl 8.6 in the meantime.
-
Is there a way to work around this issue temporarily?
-
Itcl_InvokeEnsembleMethod is failing to set a ProcErrorProc.
-
Protected common variables not visible to children
-
Throwing an error from within an itcl::ensemble causes a segmentation fault (core dump)
-
-
application error when using combobox dropdown
-
Dup of bug 115. Already fixed.
-
application error when using combobox dropdown
-
Obsolete references to "@itcl" syntax
-
Obsolete references to "@itcl" syntax
-
Extra quote in "scope" error message
-
fixed for Itcl 3.4.4 and 4.1.1
-
It appears this is an error inherited from Itcl 3.
-
Obsolete references to "@itcl" syntax
-
Extra quote in "scope" error message
-
I don't think this can get much faster given its current design. There are a lot of new calls to the Tcl core that the old code didn't make (e.g. Tcl_NewObjectInstance, dictionary functions, etc.), which is where most of the time is spent. Too bad, but I guess that's the price of progress.
-
tclconfig is a separate project core.tcl.tk/tclconfig/ See these instructions http://core.tcl.tk/itcl/wiki?name=Tracking+Itcl+Sources
-
That's a lot better! The creation time is now constant, but it's still significantly slower than 3.4.3. I'll look around some more to see if there's anything obvious. BTW, the tclconfig directory seems to be missing from the trunk.
-
ok, now synced.
-
Improvement committed to trunk. See what you think.
-
Guess we had the same plans for a Sunday afternoon. Will tackle this soon.
-
Object creation/deletion speed and memory usage
-
Well this may not be too bad. The line that creates the trouble is: https://core.tcl.tk/itcl/artifact/cf873c608adaa772?ln=272 Itcl_PreserveData() is crude and inefficient. It needs replacing with an appropriate refcounting scheme directly on the ioPtr argument.
-
It looks like the problem is in the Itcl_PreserveData() and Itcl_ReleaseData() functions in generic/itclUtil.c, which in turn call Tcl_Preserve() and Tcl_Release(). These functions use a linear search, which is why the time is increasing linearly. The Tcl documentation even states, "The mechanism is intended only for short-term use (i.e. while procedures are pending on the stack); it will not work efficiently as a mechanism for long-term reference counts." Itcl 3.4 uses a hash table implementation,...
-
On 10/27/2017 11:19 AM, Tim Tomkinson wrote: This is still a problem with Itcl 4.1.0. Itcl 3.4's object creation time is constant at about 2 µs, while Itcl 4.1.0's time increases linearly (see attachments). Is this going to be too difficult to fix based on Itcl 4's internal design? Looks like object creation must still be doing something linear in the number of existing objects. Any idea what that is? -- | Don Porter Applied and Computational Mathematics Division | | donald.porter@nist.gov Information...
-
This is still a problem with Itcl 4.1.0. Itcl 3.4's object creation time is constant at about 2 µs, while Itcl 4.1.0's time increases linearly (see attachments). Is this going to be too difficult to fix based on Itcl 4's internal design?
-
Thanks for the quick response!
-
"is object -class" fails in namespace
-
Fixed for Itcl 4.1.1
-
Confirmed. Appears this has never worked in the Itcl 4 development series.
-
"is object -class" fails in namespace
-
iwidgets fails for TCL 6.4.5
-
I am sorry to report that my builds of all those packages on an OSX Sierra system do not demonstrate a crash on the submitted script. If you can supply more information, I can try again, but if I cannot reproduce the trouble I cannot really begin to chase down what might be the problem.
-
Don, As I indicated in the bug report, this issue only happens in Mac OS X (not in Linux nor Cgywin.) And the script does not crash every time, only randomly but quite often (mostly 7 out of 10.) From my own testing, I would suggest the possibility of issue between itk 4.1.0 and TK 8.6.6 (I had reported one earlier, #115.) I can try to upgrade TK to 8.6.7 or downgrade itk to 4.0.6 as you suggested to see if it helps. However, in a broader sense, since using Tcl/Tk is not limited to one specific project...
-
Thank you for a good report. The demo script seems to work fine on a linux system. I will try on an OS X system later when I am on one. Perhaps next week. My underinformed guess at this point is you've run into some platform-specific trouble in Itk 4.1.0. or possibly Tk 8.6.6. If you have time to blindly try things, you might look into using Tcl/Tk 8.6.7 and/or Itcl/Itk 4.0.6. Will be able to give better answers after I reproduce the trouble. Should I expect a crash each time?
-
Mac OS X: random crashes of wish (tcl/tk 8.6.6) using Iwidgets (4.1.0) radiobox class
-
iwidgets 4.1.0 configure error in line 6515
-
Thomas Perschak posted a comment on ticket #116
This fixed the issue. thx!
1 >