From Newsgroup: comp.lang.tcl

Curious if optional arguments to a proc reduce its efficiency in any
way. For example, is there any difference among the following cases:

proc test {a b c} { ... }

proc test {a b {c hello}} { ... }

proc test {a {b b1} {c hello}} { ... }
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

saito <saitology9@gmail.com> wrote:

Curious if optional arguments to a proc reduce its efficiency in any
way. For example, is there any difference among the following cases:

proc test {a b c} { ... }

proc test {a b {c hello}} { ... }

proc test {a {b b1} {c hello}} { ... }

You can find out yourself:

$ rlwrap tclsh
% proc test {a b c} { }
% time [list test 1 2 3] 10000
0.754 microseconds per iteration

Extending to test the second and third procs are left as an exercise.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 2/23/2026 2:50 PM, Rich wrote:

You can find out yourself:

$ rlwrap tclsh
% proc test {a b c} { }
% time [list test 1 2 3] 10000
0.754 microseconds per iteration

Extending to test the second and third procs are left as an exercise.

That is true. So, it seems there is some slowdown as default arguments increase but assuming this is constant per args processing, it is quite
minor.

% proc test {a b c} { }
% time [list test 1 2 3] 10000
0.47484000000000004 microseconds per iteration

% proc test1 {a b {c {}}} { }
% time [list test1 1 2 3] 10000
0.63431 microseconds per iteration

% proc test1 {a b {c {}} {d {}} {e {}} {f {}} {g {}}} { }

% time [list test1 1 2 3] 10000
0.5722900000000001 microseconds per iteration

% time [list test1 1 2 3] 10000
0.62627 microseconds per iteration

% time [list test1 1 2 ] 10000
0.60965 microseconds per iteration

% time [list test1 1 2 3 4 5 6] 10000
0.56733 microseconds per iteration

% time [list test1 1 2 3 4 5 6 7] 10000
0.6530900000000001 microseconds per iteration

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* saito <saitology9@gmail.com>
| So, it seems there is some slowdown as default arguments increase but
| assuming this is constant per args processing, it is quite minor.

--<snip-snip>--
| % proc test1 {a b {c {}} {d {}} {e {}} {f {}} {g {}}} { }

| % time [list test1 1 2 3] 10000
| 0.5722900000000001 microseconds per iteration

| % time [list test1 1 2 3] 10000
| 0.62627 microseconds per iteration

As you can see from these two, there already is a rather large delta
(~10%) for identical calls. Anything in that delta is noise, not any
real difference. Also I'm not quite sure when byte compilation happens,
ISTR that this was at first call of a proc, so that first call probably
should be discarded (though it is fastest in your example :-).

| % time [list test1 1 2 ] 10000
| 0.60965 microseconds per iteration

| % time [list test1 1 2 3 4 5 6] 10000
| 0.56733 microseconds per iteration

| % time [list test1 1 2 3 4 5 6 7] 10000
| 0.6530900000000001 microseconds per iteration

IME if you repeat the individual tests multiple times, you get even
bigger variations. So instead of taking a single run and base the
result on that, repeat at least say 10 times to get an idea.

R'
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Ralf Fassel <ralfixx@gmx.de> wrote:

* saito <saitology9@gmail.com>
| So, it seems there is some slowdown as default arguments increase but
| assuming this is constant per args processing, it is quite minor.

--<snip-snip>--
| % proc test1 {a b {c {}} {d {}} {e {}} {f {}} {g {}}} { }

| % time [list test1 1 2 3] 10000
| 0.5722900000000001 microseconds per iteration

| % time [list test1 1 2 3] 10000
| 0.62627 microseconds per iteration

As you can see from these two, there already is a rather large delta
(~10%) for identical calls. Anything in that delta is noise, not any
real difference. Also I'm not quite sure when byte compilation happens,
ISTR that this was at first call of a proc, so that first call probably should be discarded (though it is fastest in your example :-).

| % time [list test1 1 2 ] 10000
| 0.60965 microseconds per iteration

| % time [list test1 1 2 3 4 5 6] 10000
| 0.56733 microseconds per iteration

| % time [list test1 1 2 3 4 5 6 7] 10000
| 0.6530900000000001 microseconds per iteration

IME if you repeat the individual tests multiple times, you get even
bigger variations. So instead of taking a single run and base the
result on that, repeat at least say 10 times to get an idea.

R'

Those time runs are already for 10000 repetitions.

The third parameter to [time] is "number of repetitions to perform".


--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* Rich <rich@example.invalid>
| > | % time [list test1 1 2 ] 10000
| > | 0.60965 microseconds per iteration
| >>
| > | % time [list test1 1 2 3 4 5 6] 10000
| > | 0.56733 microseconds per iteration
| >>
| > | % time [list test1 1 2 3 4 5 6 7] 10000
| > | 0.6530900000000001 microseconds per iteration
| >
| > IME if you repeat the individual tests multiple times, you get even
| > bigger variations. So instead of taking a single run and base the
| > result on that, repeat at least say 10 times to get an idea.

| Those time runs are already for 10000 repetitions.
| The third parameter to [time] is "number of repetitions to perform".

Yes, I know. Nevertheless, on my otherwise idle PC:

% time [list test1 1 2 3 4 5 6 7] 100000
0.60292 microseconds per iteration
% time [list test1 1 2 3 4 5 6 7] 100000
0.56502 microseconds per iteration
% time [list test1 1 2 3 4 5 6 7] 100000
0.52475 microseconds per iteration
% time [list test1 1 2 3 4 5 6 7] 100000
0.5317 microseconds per iteration
% time [list test1 1 2 3 4 5 6 7] 100000
0.4898 microseconds per iteration
% time [list test1 1 2 3 4 5 6 7] 100000
0.43831 microseconds per iteration
% time [list test1 1 2 3 4 5 6 7] 100000
0.482 microseconds per iteration
% time [list test1 1 2 3 4 5 6 7] 100000
0.44397 microseconds per iteration
% time [list test1 1 2 3 4 5 6 7] 100000
0.55761 microseconds per iteration
% time [list test1 1 2 3 4 5 6 7] 100000
0.51394 microseconds per iteration
% time [list test1 1 2 3 4 5 6 7] 100000
0.46066 microseconds per iteration
% time [list test1 1 2 3 4 5 6 7] 100000
0.48599 microseconds per iteration
% time [list test1 1 2 3 4 5 6 7] 100000
0.45478 microseconds per iteration

I.e. min 0.43831, max 0.60292 (delta ~25%). If it comes to
*micro*seconds, I think there is no 'accurate' timing this way.

R'
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 2/24/2026 11:24 AM, Ralf Fassel wrote:

* Rich <rich@example.invalid>
| >
| > IME if you repeat the individual tests multiple times, you get even
| > bigger variations. So instead of taking a single run and base the
| > result on that, repeat at least say 10 times to get an idea.

| Those time runs are already for 10000 repetitions.
| The third parameter to [time] is "number of repetitions to perform".

Maybe it got sent to a performance core vs. efficiency core :-)
I ran the tests a few times, and took the ones that fell in the middle.
But I agree, I think timing used to make more sense in single cpu days.

Yes, I know. Nevertheless, on my otherwise idle PC:

start of rant: When I think my pc is idle, MS is always either updating itself, downloading updates, or installing new services to manage these updates and downloads, checking their store services, etc. I can't even
remove some of their app's; they remain running and use the network. My
pc maker has its own software that does the same thing. Firefox and
Chrome constantly track me and send stuff out. When I think I just
opened a browser, with an empty tab sitting there, it has spawned a
dozen or so instances/services shaking up my pc. All software does this
these days. All for my benefit, of course. end of rant :-)


--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 2/24/2026 1:27 PM, saito wrote:

On 2/24/2026 11:24 AM, Ralf Fassel wrote:

* Rich <rich@example.invalid>
| >
| > IME if you repeat the individual tests multiple times, you get even
| > bigger variations.-a So instead of taking a single run and base the
| > result on that, repeat at least say 10 times to get an idea.

| Those time runs are already for 10000 repetitions.
| The third parameter to [time] is "number of repetitions to perform".

Maybe it got sent to a performance core vs. efficiency core :-)
I ran the tests a few times, and took the ones that fell in the middle. But I agree, I think timing used to make more sense in single cpu days.

Yes, I know.-a Nevertheless, on my otherwise idle PC:

start of rant: When I think my pc is idle, MS is always either updating itself, downloading updates, or installing new services to manage these updates and downloads, checking their store services, etc. I can't even remove some of their app's; they remain running and use the network.-a My pc maker has its own software that does the same thing. Firefox and Chrome constantly track me and send stuff out. When I think I just opened a browser, with an empty tab sitting there, it has spawned a dozen or so instances/services shaking up my pc. All software does this these days. All for my benefit, of course. end of rant :-)

I find using time is always 10% or different as I run the same 100,000 times multiple times. It could be caches or most anything. The new timerate command is supposed to be more accurate.

On windows, I launch at startup the sysinternals (part of MS) tool process explorer. There's an option to place a small tray icon that has a histogram of cpu usage, and hovering over it will tell you the top cpu user.

One can right-click and choose system information and get a graph of about the last minute or two of the cpu usage, including an option to show one graph per cpu core. Hovering over the graph can also show you the top cpu user for each core during that time.

And when that fails, my computer fan will often turn on when something is using a lot of cpu :)

-et

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 2/24/2026 4:40 PM, et99 wrote:

On windows, I launch at startup the sysinternals (part of MS) tool
process explorer. There's an option to place a small tray icon that has
a histogram of cpu usage, and hovering over it will tell you the top cpu user.

Lots of good info.
I am not a power user or heavy user or anything like that. But I do occasionally use the basic taskbar when things lock up or Windows
taskbar stops responding, etc. Sometimes it helps, sometimes the only
choice is to restart-update, or to reset.


--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

saito <saitology9@gmail.com> wrote:

On 2/24/2026 4:40 PM, et99 wrote:

On windows, I launch at startup the sysinternals (part of MS) tool
process explorer. There's an option to place a small tray icon that has
a histogram of cpu usage, and hovering over it will tell you the top cpu
user.

Lots of good info.
I am not a power user or heavy user or anything like that. But I do occasionally use the basic taskbar when things lock up or Windows
taskbar stops responding, etc. Sometimes it helps, sometimes the only
choice is to restart-update, or to reset.

An alternate is to use Linux, where you can be much more in control
(although this does depend on the distro you install, something like
Ubuntu will be "more windows like" in all the stuff it will do in the background).
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* saito <saitology9@gmail.com>
| start of rant: When I think my pc is idle, MS is always either
| updating itself, downloading updates, or installing new services to
| manage these updates and downloads, checking their store services,
| etc.

Well... what should I say :-)

top - 11:47:41 up 6 days, 16:35, 1 user, load average: 0,30, 0,43, 0,30
Tasks: 273 total, 2 running, 270 sleeping, 0 stopped, 1 zombie
%Cpu0 : 0,8 us, 0,6 sy, 0,0 ni, 98,5 id, 0,0 wa, 0,0 hi, 0,1 si, 0,0 st
%Cpu1 : 3,2 us, 2,0 sy, 0,0 ni, 94,8 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu2 : 1,4 us, 1,3 sy, 0,1 ni, 97,2 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu3 : 0,4 us, 0,3 sy, 0,0 ni, 99,3 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu4 : 1,3 us, 1,0 sy, 0,0 ni, 97,7 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu5 : 9,6 us, 0,8 sy, 0,0 ni, 89,6 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu6 : 1,3 us, 1,5 sy, 0,0 ni, 97,2 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu7 : 0,3 us, 0,3 sy, 0,0 ni, 99,2 id, 0,2 wa, 0,0 hi, 0,0 si, 0,0 st

The 'id' is the "idle column", Debian-13.

R'
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Ralf Fassel <ralfixx@gmx.de> wrote:

* saito <saitology9@gmail.com>
| start of rant: When I think my pc is idle, MS is always either
| updating itself, downloading updates, or installing new services to
| manage these updates and downloads, checking their store services,
| etc.

Well... what should I say :-)

top - 11:47:41 up 6 days, 16:35, 1 user, load average: 0,30, 0,43, 0,30
Tasks: 273 total, 2 running, 270 sleeping, 0 stopped, 1 zombie
%Cpu0 : 0,8 us, 0,6 sy, 0,0 ni, 98,5 id, 0,0 wa, 0,0 hi, 0,1 si, 0,0 st
%Cpu1 : 3,2 us, 2,0 sy, 0,0 ni, 94,8 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu2 : 1,4 us, 1,3 sy, 0,1 ni, 97,2 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu3 : 0,4 us, 0,3 sy, 0,0 ni, 99,3 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu4 : 1,3 us, 1,0 sy, 0,0 ni, 97,7 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu5 : 9,6 us, 0,8 sy, 0,0 ni, 89,6 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu6 : 1,3 us, 1,5 sy, 0,0 ni, 97,2 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu7 : 0,3 us, 0,3 sy, 0,0 ni, 99,2 id, 0,2 wa, 0,0 hi, 0,0 si, 0,0 st

The 'id' is the "idle column", Debian-13.

Slackware 15, but this /is/ after I forced firefox to stop (it runs
things in the background so often I created a Tcl script that "kill
-STOP's" it when I want it to be paused).

top - 11:26:11 up 38 days, 15:27, 45 users, load average: 0.35, 0.56, 0.46 Tasks: 368 total, 1 running, 343 sleeping, 22 stopped, 2 zombie
%Cpu0 : 0.3 us, 0.3 sy, 0.0 ni, 99.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu1 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu2 : 0.0 us, 0.0 sy, 0.0 ni, 99.0 id, 1.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu3 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu4 : 0.0 us, 0.3 sy, 0.0 ni, 99.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu5 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu6 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu7 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st --- Synchronet 3.21b-Linux NewsLink 1.2