speed of script execution - Protocols

This is a discussion on speed of script execution - Protocols ; Can anyone tell me why there is such a huge time discrepency between the execution of the following scripts. The only difference is the curly braces. I'm running on an ARM SBC from a flash drive, if that makes any ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: speed of script execution

  1. speed of script execution

    Can anyone tell me why there is such a huge time discrepency between
    the execution of the following scripts. The only difference is the
    curly braces. I'm running on an ARM SBC from a flash drive, if that
    makes any difference.

    ---- testx.ksc ----
    #!/usr/bin/kermit +
    { assign \%p 1, set line /dev/ttyAM\%p }
    { close }
    exit

    ---- testy.ksc ----
    #!/usr/bin/kermit +
    assign \%p 1, set line /dev/ttyAM\%p
    close
    exit

    -- test results --
    $ time ./testx.ksc
    real 0m 0.60s
    user 0m 0.04s
    sys 0m 0.06s

    $ time ./testy.ksc
    real 0m 0.09s
    user 0m 0.05s
    sys 0m 0.04s

    Yes, when I go back and forth between the two scripts, the times of
    each stay consistent, so the second one shown above didn't just run
    faster because it was second; if I go back and run testx.ksc again, it
    takes 0.60s.

    Of course "don't use the curly braces" but this is part of a larger
    system that I have distilled down to this very simple example, so
    that's really not an option.

    Any ideas or input would be greatly appreciated.


  2. Re: speed of script execution

    On 2006-04-20, tomviolin wrote:
    : Can anyone tell me why there is such a huge time discrepency between
    : the execution of the following scripts. The only difference is the
    : curly braces. I'm running on an ARM SBC from a flash drive, if that
    : makes any difference.
    :
    : ---- testx.ksc ----
    : #!/usr/bin/kermit +
    : { assign \%p 1, set line /dev/ttyAM\%p }
    : { close }
    : exit
    :
    : ---- testy.ksc ----
    : #!/usr/bin/kermit +
    : assign \%p 1, set line /dev/ttyAM\%p
    : close
    : exit
    :
    : -- test results --
    : $ time ./testx.ksc
    : real 0m 0.60s
    : user 0m 0.04s
    : sys 0m 0.06s
    :
    : $ time ./testy.ksc
    : real 0m 0.09s
    : user 0m 0.05s
    : sys 0m 0.04s
    :
    : Yes, when I go back and forth between the two scripts, the times of
    : each stay consistent, so the second one shown above didn't just run
    : faster because it was second; if I go back and run testx.ksc again, it
    : takes 0.60s.
    :
    : Of course "don't use the curly braces" but this is part of a larger
    : system that I have distilled down to this very simple example, so
    : that's really not an option.
    :
    As in C, the braces mark a block, entry to and exit from which carries some
    setup and takedown cost. When you have only one or two statements in the
    block, that cost is a lot higher, proportionally, than if you have a lot of
    statements in it.

    Block structure is a convenience and an aid to writing readable source code,
    but it's not a necessity. Every block structure can be decomposed into
    something more rudimentary and lest costly in execution, using GOTOs or
    whatever. In fact, that's what happens internally anyway. The only
    difference is that with true blocks, various buffers and variables and other
    context have to be stacked.

    If you have encountered a serious bottleneck in a real application, let me
    know, maybe something can be done about it.

    - Frank

  3. Re: speed of script execution

    Frank da Cruz wrote:
    > On 2006-04-20, tomviolin wrote:
    > : Can anyone tell me why there is such a huge time discrepency between
    > : the execution of the following scripts. The only difference is the
    > : curly braces.
    > As in C, the braces mark a block, entry to and exit from which carries some
    > setup and takedown cost. When you have only one or two statements in the
    > block, that cost is a lot higher, proportionally, than if you have a lot of
    > statements in it.
    >
    > Block structure is a convenience and an aid to writing readable source code,
    > but it's not a necessity. Every block structure can be decomposed into
    > something more rudimentary and lest costly in execution, using GOTOs or
    > whatever. In fact, that's what happens internally anyway. The only
    > difference is that with true blocks, various buffers and variables and other
    > context have to be stacked.
    >


    Frank,

    I have had an idea. I am somewhat familiar with how Kermit breaks down
    structured code into GOTOs and the like (the code shows up when you
    have SET MACRO ECHO ON for example).

    What if there was a way to do that decomposition in a function and then
    save the results to a new command file? For example, part of my
    "larger system" does this:

    -- begin kermit script --
    take \m(connect_id).ksc ; always contains gd_connect
    ; and gd_disconnect macro definitions
    take \m(device_id).ksc ; always contains a gd_acquire macro
    definition
    fopen /write \%f "getdata.ksc" ; to be executed later
    fwrite /line \%f "\m(gd_connect)"
    fwrite /line \%f "\m(gd_acquire)"
    fwrite /line \%f "\m(gd_disconnect)"
    fclose \%f

    This basically turns a set of macros into inline code to be executed
    later. This works great for very simple macro definitions that have no
    blocks in them. As soon as blocks are introduced, wham, the execution
    time goes way up.

    What I'm proposing is some function \fdecompose() that could perhaps be
    called like this:

    \fdecompose(\m(gd_connect))

    that would take the "inlining" process to the next level, and produce
    the lower-level code with all the "goto .._blah" stuff, sort of like
    compiling to p-code in a way.

    Or, is there a way to do this already?

    -Tom


  4. Re: speed of script execution

    Frank da Cruz wrote:
    > On 2006-04-20, tomviolin wrote:
    > : Can anyone tell me why there is such a huge time discrepency between
    > : the execution of the following scripts. The only difference is the
    > : curly braces. I'm running on an ARM SBC from a flash drive, if that
    > : makes any difference.
    > :
    > : ---- testx.ksc ----
    > : #!/usr/bin/kermit +
    > : { assign \%p 1, set line /dev/ttyAM\%p }
    > : { close }
    > : exit
    > :
    > : ---- testy.ksc ----
    > : #!/usr/bin/kermit +
    > : assign \%p 1, set line /dev/ttyAM\%p
    > : close
    > : exit
    > :
    > : -- test results --
    > : $ time ./testx.ksc
    > : real 0m 0.60s
    > : user 0m 0.04s
    > : sys 0m 0.06s
    > :
    > : $ time ./testy.ksc
    > : real 0m 0.09s
    > : user 0m 0.05s
    > : sys 0m 0.04s
    > :
    > :
    > As in C, the braces mark a block, entry to and exit from which carries some
    > setup and takedown cost. When you have only one or two statements in the
    > block, that cost is a lot higher, proportionally, than if you have a lot of
    > statements in it.
    >

    [ stuff skipped ]
    >
    > If you have encountered a serious bottleneck in a real application, let me
    > know, maybe something can be done about it.
    >
    > - Frank


    I have played a bit with my examples as well as my larger system, and
    have generated the following two examples, changed only with addition
    of a couple of echo statements:

    -- testx.ksc --
    #!/usr/bin/kermit +
    { assign \%p 1, set line /dev/ttyAM\%p }
    echo test 1
    { close }
    echo test 2
    exit

    -- testy.ksc --
    #!/usr/bin/kermit +
    assign \%p 1, set line /dev/ttyAM\%p
    echo test 1
    close
    echo test 2
    exit

    Again, testy.ksc runs much faster. However, I am observing that, with
    the slower testx.ksc script, that "test 1" appears almost instantly,
    and that the vast majority of the 0.6 seconds is spent between "test 1"
    and "test 2" appearing, with "test 2" appearing right before the
    program ends.

    Then, I further modified testx.ksc as follows:

    --- testx1.ksc ---
    #!/usr/bin/kermit +
    { assign \%p 1, set line /dev/ttyAM\%p }
    echo test 1
    { echo test 1a, close, echo test 1b }
    echo test 2
    exit

    Now of course the output is:

    $ ./testx1.ksc
    test 1
    test 1a
    test 1b
    test 2

    and the vast majority of the pause is between the appearance of "test
    1a" and "test 1b", thus demonstrating that the "close" statement is the
    cause of the problem.

    PLUS, look at the "time" output again (results very similar to the
    prior examples):

    $ time ./testx.ksc
    test 1
    test 2
    real 0m 0.63s
    user 0m 0.05s
    sys 0m 0.07s

    $ time ./testy.ksc
    test 1
    test 2
    real 0m 0.09s
    user 0m 0.04s
    sys 0m 0.05s

    Notice that the "user" and "sys" times for testx.ksc and testy.ksc are
    comparable and that for testy.ksc, the sum of "user" and "sys" are
    close to (or apparently exactly) the value for "real". However, the
    "real" time for testx.ksc is way off the chart compared to the sum of
    "user" and "sys" thus seeming to indicate that kermit is sleeping,
    waiting for I/O, or otherwise in some sort of suspended state for about
    0.51s. Doesn't seem like time spent in setup or takedown of data
    structures to me.

    It would appear that the "close" statement is the culprit. Why? And
    why does it delay only for testx.ksc and not testy.ksc?


  5. Re: speed of script execution

    On 2006-04-21, tomviolin wrote:
    : ...
    : It would appear that the "close" statement is the culprit. Why? And
    : why does it delay only for testx.ksc and not testy.ksc?
    :
    Closing a serial port can take time, depending on the driver -- maybe it's
    waiting for some modem signals to react. As to why it takes longer in
    a block than at top level, I confess, I haven't a clue. I'll try to find
    time to look at this but if you run across anything else in the meantime
    let me know.

    - Frank

+ Reply to Thread