Command line LOADBTM

[vefatica]

Would this be possible (in a future version) ... A command line version of
LOADBTM (or another name) together with UNLOADBTM and RUNBTM?

The user could

LOADBTM file.btm

and run it at will with RUNBTM, unloading it at an appropriate time.

This would make speed testing more critical. For example, instead of

timer & for /l %z in (1601,1,2008) agetodate.btm %@makeage[%z-01-01] & timer

one could

loadbtm agetodate.btm
timer & for /l %z in (1601,1,2008) runbtm %@makeage[%z-01-01] & timer

Without having to load (actually read) the BTM with each iteration, the timing
would more accurately show the significance of any tweaks.
--
- Vince

 

[rconn]

vefatica wrote:

> Would this be possible (in a future version) ... A command line version of
> LOADBTM (or another name) together with UNLOADBTM and RUNBTM?
>
> The user could
>
> LOADBTM file.btm
>
> and run it at will with RUNBTM, unloading it at an appropriate time.
>
> This would make speed testing more critical. For example, instead of
>
> timer & for /l %z in (1601,1,2008) agetodate.btm %@makeage[%z-01-01] & timer
>
> one could
>
> loadbtm agetodate.btm
> timer & for /l %z in (1601,1,2008) runbtm %@makeage[%z-01-01] & timer
>
> Without having to load (actually read) the BTM with each iteration, the
> timing would more accurately show the significance of any tweaks.

It would require rewriting the batch parser. I'm a bit dubious that
marginally more precise loop timing tests are worth a couple of weeks of
development time (that could be spent on more widely useful features),
but I'll add it to the suggestion list.

It could be done in a plugin, if you don't mind writing your own parser ...

Rex Conn
JP Software

 

[vefatica]

On Wed, 04 Jun 2008 22:53:33 -0500, you wrote:

>> loadbtm agetodate.btm
>> timer & for /l %z in (1601,1,2008) runbtm %@makeage[%z-01-01] & timer
>>
>> Without having to load (actually read) the BTM with each iteration, the
>> timing would more accurately show the significance of any tweaks.

>It would require rewriting the batch parser.

That surprises me. As I see it (from the outside) you already have a mechanism
for reading a BTM into memory and then running it. I was thinking you could
just separate those two chores and leave the BTM in memory.
--
- Vince

 

[rconn]

vefatica wrote:

> Quote:
> >> loadbtm agetodate.btm
> >> timer & for /l %z in (1601,1,2008) runbtm %@makeage[%z-01-01] & timer
> >>
> >> Without having to load (actually read) the BTM with each iteration, the
> >> timing would more accurately show the significance of any tweaks.
>
>
> Quote:
> >It would require rewriting the batch parser.
>
> That surprises me. As I see it (from the outside) you already have a
> mechanism for reading a BTM into memory and then running it. I was

> thinking you could just separate those two chores and leave
> the BTM in memory.

It's the "just separate those two chores" part that would require
rewriting the parser. And if you (1) tried to run another batch file
after the loadbtm and before the unloadbtm, or (2) called or chained to
another batch file from the first one, it would require the DWIM parser.

Rex Conn
JP Software

 

[vefatica]

On Wed, 04 Jun 2008 23:26:15 -0500, you wrote:

> > thinking you could just separate those two chores and leave
> > the BTM in memory.
>
>It's the "just separate those two chores" part that would require
>rewriting the parser. And if you (1) tried to run another batch file
>after the loadbtm and before the unloadbtm, or (2) called or chained to
>another batch file from the first one, it would require the DWIM parser.

I figured (1) would be a no-no or would cause an auto-unloading. For me,
calling and chaining could be simply disallowed, or cause a reversion to normal
behavior. If I wanted to do testing that specific, I'd just do without calling
and chaining (neither or which I use much anyway).

A question: In tweaking that BTM I sent, I noticed that extra space (comments,
blank lines) resulted in significantly slower tests. No doubt they affect the
load time. Are they kept in memory or discarded when a BTM is loaded?
--
- Vince

 

[p.f.moore]

On 05/06/2008, vefatica <> wrote:

> This would make speed testing more critical. For example, instead of
>
> timer & for /l %z in (1601,1,2008) agetodate.btm %@makeage[%z-01-01] & timer
>
> one could
>
> loadbtm agetodate.btm
> timer & for /l %z in (1601,1,2008) runbtm %@makeage[%z-01-01] & timer
>
> Without having to load (actually read) the BTM with each iteration, the timing
> would more accurately show the significance of any tweaks.

Could you not add

timer & for /l %z in (1601,1,2008) gosub main %@makeage[%z-01-01] & timer
quit
:main [arg]

at the top of your file, plus a return at the end, to get effectively
the same test precision, without any changes to TCMD?

Paul.

 

[rconn]

vefatica wrote:

> A question: In tweaking that BTM I sent, I noticed that extra space
> (comments,
> blank lines) resulted in significantly slower tests. No doubt they
> affect the
> load time. Are they kept in memory or discarded when a BTM is loaded?

They are not discarded as this would require a preparser pass. (The
batch file is loaded as a block, not line-by-line.)

If you run BATCOMP it will remove blank lines and "::" comments from the
target.

Rex Conn
JP Software

 

[samintz]

I don't suppose there's a back-door way to pass an open file handle to the
batch engine? I was thinking that Vince's MMF plugin could be easily
enhanced to load the batch file and pass the memory mapped file to the
parser.

-Scott




rconn <>
06/04/2008 11:53 PM
Please respond to



To
[email protected]
cc

Subject
RE: [Support-t-136] Command line LOADBTM






vefatica wrote:

Quote:

> Would this be possible (in a future version) ... A command line version

of

> LOADBTM (or another name) together with UNLOADBTM and RUNBTM?
>
> The user could
>
> LOADBTM file.btm
>
> and run it at will with RUNBTM, unloading it at an appropriate time.
>
> This would make speed testing more critical. For example, instead of
>
> timer & for /l %z in (1601,1,2008) agetodate.btm %@makeage[%z-01-01] &

timer

>
> one could
>
> loadbtm agetodate.btm
> timer & for /l %z in (1601,1,2008) runbtm %@makeage[%z-01-01] & timer
>
> Without having to load (actually read) the BTM with each iteration, the
> timing would more accurately show the significance of any tweaks.

It would require rewriting the batch parser. I'm a bit dubious that
marginally more precise loop timing tests are worth a couple of weeks of
development time (that could be spent on more widely useful features),
but I'll add it to the suggestion list.

It could be done in a plugin, if you don't mind writing your own parser
...

Rex Conn
JP Software

 

[Steve Fabian]

p.f.moore wrote:
| On 05/06/2008, vefatica <> wrote:
|
|
| ---Quote---
|| This would make speed testing more critical. For example, instead of
||
|| timer & for /l %z in (1601,1,2008) agetodate.btm
|| %@makeage[%z-01-01] & timer
||
|| one could
||
|| loadbtm agetodate.btm
|| timer & for /l %z in (1601,1,2008) runbtm %@makeage[%z-01-01]
|| & timer
||
|| Without having to load (actually read) the BTM with each iteration,
|| the timing would more accurately show the significance of any tweaks.
| ---End Quote---
| Could you not add
|
| timer & for /l %z in (1601,1,2008) gosub main %@makeage[%z-01-01] &
| timer quit
|| main [arg]
|
| at the top of your file, plus a return at the end, to get effectively
| the same test precision, without any changes to TCMD?

Variations on the same theme:

1/ Perform the GOSUB above once for an arbitrary parameter to ensure it is
preparsed

2/ Perform the GOSUB above for a set of handcrafted parameters that exercise
each branch at least once

3/ eliminate the @makeage by building a table of value to use

To just compare the execution time of two variants of the same code snippet
you should execute just the snippets 1,000 times (or 10,000 times) each with
unchanging parameters. If there are branches in the snippets, you need to
time them separately for each possible path. In the end you can come of with
a worst-case timing.

--
Steve

 

[rconn]

samintz wrote:

> I don't suppose there's a back-door way to pass an open file handle to the
> batch engine?

Nope; that'd also require a batch parser rewrite.

Rex Conn
JP Software