Well, since I haven't yet gotten any answers re. my previous question(s) about "@ExecStr" ;) , I am now in the middle of rewriting things to use the "Start" command instead of the "@Exec..." function. And this is a case, where while not at all what I would call real important, I can't help but wonder what the "performance" impact is, if any.

So, as I starting point, I've always had the impression that, from the user's perspective, a batch file was essentially the same thing as a "program" (i.e., .exe file) except that the interpreter in TCC was used to execute it, and therefore, if a file to be executed had a ".btm" extension, a (new) TCC instance would be implicitly automatically started to execute it when attempting to run it from the "Start" command with no differences between that and executing just an ".exe" file, for instance.

Well, this is yet another case where that "impression" seems to have been wrong. You see, I was starting a new batch file by using (this is for example, only; although it is an example that has been tested) something like "Start /L "Do Essentially Nothing" DoEssentiallyNothing" where "DoEssentiallyNothing" was a .btm file that just echoed "Did Nothing!!!", and this mostly worked other than the unexpected error message at the top of the newly-created TCC Window "TCC: (Sys) The parameter is incorrect. "/L"", clearly not what I was expecting. Well, I was not at all surprised to figure out that this was not at all an issue when I replace the above "Start" command with "Start "Do Essentially Nothing" /L TCC DoEssentiallyNothing" in which I, as you can easily see, explicitly invoke TCC to run the batch file. Well, to put it simply, I was trying to use the "/L" parameter to speed up things a bit by not making the start command copy aliases, the directory history, and the list of defined functions because I thought that things would run faster if all of those things didn't happen. And, since I have to explicitly invoke TCC to run the batch file to use any of the "/L." parameters, I can't help but wonder if just running the batch file "natively" without the "/L." parameters would be faster than explicitly invoking TCC (which then has to "evaluate" whether what is being executed is a batch file a second time rather than allowing the "Start" command itself to implicitly determine that fact). But I will also note here that #1. The may be no "performance" penalty at all, and #2. Explicitly invoking TCC directly (rather than having the "Start" command implicitly invoking it) might actually faster than the first alternative. So the question is, which is it?

Administrator

So, as I starting point, I've always had the impression that, from the user's perspective, a batch file was essentially the same thing as a "program" (i.e., .exe file) except that the interpreter in TCC was used to execute it, and therefore, if a file to be executed had a ".btm" extension, a (new) TCC instance would be implicitly automatically started to execute it when attempting to run it from the "Start" command with no differences between that and executing just an ".exe" file, for instance.

START will *always* start a new session, regardless of whether the command is an internal, external, batch file, or alias.

Using /L might shave a couple of milliseconds off the batch file execution time -- but it'll probably also not work as expected unless you never use aliases, user-defined functions, or set anything in your TCSTART. If you ran that batch file a few million times, the time savings might approach a fraction of the time you spent wondering about it and composing your message.