Declined INCLUDE Command for Including Batch Code

[Jay Sage]

I think it would be useful to have a command (e.g., INCLUDE) to read the contents of a specified file (using full TCC syntax, of course) into a batch file. This would allow one to have code that is used in more than one batch file or different code for different environments (possibly determined in the main code).

CALL (and to some extent GOSUB) can accomplish this, but if the code is in a loop, it is much faster (5x in an experiment I just did) to have the code resident in the batch file rather than being reloaded each time it is used.

I make this suggestion only if this is easy to implement. For the application I have now, the extra time of the CALL is not significant.

 

[Joe Caverly]

If you put your code in a LIBRARY function, does the speed improve?

I used to use GOSUB "filename",
but creating/loading the LIBRARY function near the beginning of the batch file,
or loading the LIBRARY function in TCSTART.BTM,
eliminated the need for me to use GOSUB "filename".

Joe

 

[Joe Caverly]

Here's a method that I have used to include a file...

Test.btm

@setlocal
@echo off

set File2Include=include.txt

iff not exist %File2Include then
  echo %File2Include Not Found.
  quit
endif

on error gosub IncludeFile

set _test=Include succesful
Gosub test

on error

echo End of Job.

endlocal

:EndOfJob
quit

:IncludeFile
echo %_batchname does not have the :test subroutine.
echo Including that subroutine now.
type %File2Include >> %_batchname
echo Restarting %_batchname
call %_batchname
quit
Return

Include.txt

:test
echo %_test
return

First run...

R:\>test.btm
R:\test.btm does not have the :IncludeFile subroutine.
Including that subroutine now.
Restarting R:\test.btm
Include succesful
End of Job.

Subsequent runs...

R:\>test.btm
Include successful
End of Job.

Joe

 

[vefatica]

[I'm sort of guessing here.] It seems that this might be feasible only of the included lines go at the end (after a QUIT). If that's the intention, to be useful, the included code should only include subroutines. Is that what you have in mind? That might not be too hard, especially if the INCLUDE statements are also at the end.

 

[Jay Sage]

It seems that this might be feasible only of the included lines go at the end (after a QUIT).

I guess that depends on how a BTM file is read into memory. It would require detecting a line with the INCLUDE command, which might slow down all BTM files and definitely not worth the trouble. Compilers generally support include files, but speed is not the issue there.

My idea probably is not a good one. The CALL command achieves what I wanted (and I verified that it can effectively include arbitrary code, not just subroutines). If the application is speed-sensitive, then I just just copy the "include" code into the file myself.

 

[Joe Caverly]

When a .btm is loaded into memory,
are the streams attached to the .btm loaded into memory?

@setlocal
@echo off

COMMENT
Contents of include.txt

:test
echo %_test
return
ENDCOMMENT

set _test=Okay.

set File2Include=include.txt

copy %File2Include %_batchname:%File2Include
dir test.btm /: /b
type %_batchname:%File2Include

Gosub "%_batchname:%File2Include" test

endlocal
quit

Maybe attaching your INCLUDE files as streams would be faster?

Joe

 

[vefatica]

When a .btm is loaded into memory,
are the streams attached to the .btm loaded into memory?

I doubt it. When you call a BTM I don't think TCC even knows it has streams. I have a few BTMs which refer to their own streams but I doubt that's any more efficient than the info being in a separate file.

 

[Joe Caverly]

I personally prefer using LIBRARY functions of tested code,
instead of GOSUBing.

LIBRARY code is always in memory,
thus faster for me.

Joe

 

[Jay Sage]

I just did a quick experiment with code that just increments a variable and is in a loop that runs 10K times. The results could be quite different with more complex code, but this gives one some idea.

• When the code was directly inline in the main BTM file, the run time was 8.9 seconds.
• When the code was called as a subroutine at the end of the main file, the run time was 12.8 seconds.
• When the code was CALLed from another BTM file, the run time was 24.3 seconds.
• Finally, when the code was run from a library, the run time was 15.5 seconds.

So, it looks as though it is fastest to include the code in the main BTM file in one form or another, but a library call is faster than calling another BTM file. I should add that my computer has a solid-state disk drive. Calling a second batch file could be much slower with a slow disk drive.

 

[rconn]

I think it would be useful to have a command (e.g., INCLUDE) to read the contents of a specified file (using full TCC syntax, of course) into a batch file. This would allow one to have code that is used in more than one batch file or different code for different environments (possibly determined in the main code).

CALL (and to some extent GOSUB) can accomplish this, but if the code is in a loop, it is much faster (5x in an experiment I just did) to have the code resident in the batch file rather than being reloaded each time it is used.

I make this suggestion only if this is easy to implement. For the application I have now, the extra time of the CALL is not significant.

It's unclear to me what advantage this would have over the existing LIBRARY command.

 

[Jay Sage]

It would just be simpler and more intuitive. However, on further thought, it doesn't seem to be a very good idea. Being able to "include" code inline makes sense for compilers, since it's not a problem if a compiler spends a little extra time reading in "include" files as the source code is processed.

For the cases I actually have in mind, the CALL command is entirely sufficient (now that I realize that it can contain arbitrary commands that will be executed at that point in the script). For production scripts where speed is important, the extra labor of loading a library, running its code in the right place, and then removing the library code is reasonable.