Transient TCCs slow compared to transient CMDs

[nickles]

Preface: When calling GVim in diff mode (the program used is not really of importance...) GVim would open two transient shells one by one.

If I call GVim from cmd (COMSPEC=...cmd.exe) it would open the diff (for a specific combination of files) immediately; you merely see two black windows pop up and disappear.

Doing the same from tcc (even if the first command in tcstart.cmd is "cancel") the startup takes *considerably* longer.

I assume this is due to license checking issues.
In case JPSoft can confirm this, would it be possible to skip these checks for shells with %_TRANSIENT = 1?

nickles

 

[rconn]

Preface: When calling GVim in diff mode (the program used is not really of importance...) GVim would open two transient shells one by one.

If I call GVim from cmd (COMSPEC=...cmd.exe) it would open the diff (for a specific combination of files) immediately; you merely see two black windows pop up and disappear.

Doing the same from tcc (even if the first command in tcstart.cmd is "cancel") the startup takes *considerably* longer.

I assume this is due to license checking issues.
In case JPSoft can confirm this, would it be possible to skip these checks for shells with %_TRANSIENT = 1?

nickles

It is not possible to skip the registration check; that is done before any of the TCC code is loaded or executed.

However, the registration check takes about 30ms on an average machine, so that's not going to be your problem. Loading TCC and all of its dll's (many many many more than CMD loads) usually takes about 100-150 ms. If you're seeing a substantially longer load time it's probably due to your TCSTART and/or TCMD.INI settings.

 

[nickles]

After your answer I fiddled around and used procmon to find that even when starting tcc with the /c switch, about 5000(!) write operations (FASTIO_WRITE) on the defined history file (with an average size of about 20(!!!) bytes) were made (as compared to about 20 read operations with an average size of 4096 bytes).

tcmd.ini doesn't seem to be an issue at all, because - according to the log - it was not read in transient mode.

These findings might very well explain the slow startup behavior.

So, the question seems to be if there is a way to prevent tcc from writing to the HIS file in transient mode (or if this make sense at all)...

nickles

 

[vefatica]

On Fri, 05 Jun 2009 12:10:53 -0500, nickles <> wrote:

|So, the question seems to be if there is a way to prevent tcc from writing to the HIS file in transient mode (or if this make sense at all)...

If you're loading a history file in tcstart.btm, you could

if %_transient NE 1 .and. %_pipe NE 1 history /r ...

If it suits you, consider using SHRALIAS. It keeps all the lists (hist,
dirhist, alias, function) in memory while no instance of TCC is running. If you
start TCC using global lists (INI directive) they're already in place.
--
- Vince

 

[Stephen Howe]

If you're loading a history file in tcstart.btm, you could

if %_transient NE 1 .and. %_pipe NE 1 history /r ...

If it suits you, consider using SHRALIAS. It keeps all the lists (hist,
dirhist, alias, function) in memory while no instance of TCC is running. If you
start TCC using global lists (INI directive) they're already in place.

Vince, is all of this in the Wiki?

If it is not, it would nice to have "model" tcstart.btm & tcexit.btm's in the Wiki, which have remmed out commands and comments with the pros/cons as to why you want such a command in tcstart.btm & tcexit.btm.

Intermediate users of TCC would get a leg up as to what is "best practice" for TCC, what makes it faster etc.

Cheers

Stephen Howe

 

[vefatica]

On Fri, 05 Jun 2009 16:00:43 -0500, Stephen Howe <> wrote:

|---Quote---
|
|If you're loading a history file in tcstart.btm, you could
|
|if %_transient NE 1 .and. %_pipe NE 1 history /r ...
|
|If it suits you, consider using SHRALIAS. It keeps all the lists (hist,
|dirhist, alias, function) in memory while no instance of TCC is running. If you
|start TCC using global lists (INI directive) they're already in place.
|---End Quote---
|
|Vince, is all of this in the Wiki?
|
|If it is not, it would nice to have "model" tcstart.btm & tcexit.btm's in the Wiki, which have remmed out commands and comments with the pros/cons as to why you want such a command in tcstart.btm & tcexit.btm.
|
|Intermediate users of TCC would get a leg up as to what is "best practice" for TCC, what makes it faster etc.

I know nothing of the wiki. I imagine the useful things folks do in TCSTART and
TCEXIT are very numerous and site-particular. As for what's "best" ... who
knows?
--
- Vince

 

[nickles]

Thanks for the answer Vince.

...however...

I forgot to mention that I

1) always keep open at least one instance of tcc.exe (not using sharealias)
2) tested this with the /i switch[es] and an tcstart.btm containing a "cancel" after the initial "@echo off"

Same results. I'm wondering why tcc would perform such a lot of small writes to the history file for a transient shell (even for an interactive one this doesn't seem to make much sense anyway...)

I'd rather see this behavior changed or be able to switch it off.

nickles