Something in my INI file is slowing TCC down

May 20, 2008
Syracuse, NY, USA
With the same INI file, TCC v28 does this much slower than TCC v24. These differing observations are very reproduceable.

v:\> *ver
TCC  28.02.18 x64   Windows 10 [Version 10.0.19044.2251]

v:\> echo %_ininame

v:\> timer /q on & do i=1 to 10000 ( set var=%@len[foo] ) & timer off
Timer 1 off: 22:44:34  Elapsed: 0:00:02.854

v:\> *ver
TCC  28.02.18 x64   Windows 10 [Version 10.0.19044.2251]

v:\> echo %_ininame

v:\> timer /q on & do i=1 to 10000 ( set var=%@len[foo] ) & timer off
Timer 1 off: 22:45:16  Elapsed: 0:00:06.354

I'm engaged in the laborious process of figuring out which directive is causing this. Does anyone have a clue about what might be going on? Even a guess could save me hours.

P.S., @LEN isn't special. I first noticed this testing a plugin variable function.
I found it (luckily, quickly)! I had command logging on. I did that a few weeks ago to test something. Turning it off fixed the problem.

The log file shows that everything is logged, including 10000 entries for each of the DO commands in my previous post. It's no wonder that it slowed things down. The log file was over 300 MB.
In a sense, some commands get logged twice. Rex, is that WAD?

v:\> log /w v:\command.log on

v:\> do i=1 to 10000 (noop %@mrand[0])

v:\> log off

v:\> d command.log
2022-11-12  21:38       1,013,991  command.log

v:\> tail command.log
[2022-11-12 21:38:37][6680] noop 17247513745096462412
[2022-11-12 21:38:37][6680] (noop %@mrand[0])
[2022-11-12 21:38:37][6680] noop 1865527751065525928
[2022-11-12 21:38:37][6680] (noop %@mrand[0])
[2022-11-12 21:38:37][6680] noop 2882385921064738709
[2022-11-12 21:38:37][6680] (noop %@mrand[0])
[2022-11-12 21:38:37][6680] noop 7493497069582125351
[2022-11-12 21:38:37][6680] (noop %@mrand[0])
[2022-11-12 21:38:37][6680] noop 16620225006652134483
[2022-11-12 21:38:41][6680] log off

I don't know what your "noop" is doing.

But a command will be logged each time through the parser, and command groups are run twice -- once to gather the grouping, and once after stripping the enclosing ( )'s.
Aha! It was the command group. That makes sense.

NOOP just does return 0;. I use it when timing things to eliminate as much overhead as possible. Is there a better way?

That brings up questions that I've long wanted to ask. To resolve the name of a command (or internal variable or variable function) TCC must do some kind of search. Is it a linear search, binary search ... something even better? Are names of internals searched before names from plugins? I have looked (casually) and never saw evidence that the name itself mattered.
Binary search for internal commands (and variables). Linear search for plugin commands (which comes before internal commands).

Thanks! Here are several guesses. Please tell me how I did.

1. TCC loads plugins in the FindFirstFile/FindNextFile order.
2. On NTFS that order is alphabetical.
3. In resolving a name, TCC searches plugin by plugin in the order they were loaded.

Similar threads