Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Command line LOADBTM

May
12,845
164
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
 
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
 
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
 
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
 
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
 
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.
 
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
 
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
 
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
 

Similar threads

Back
Top