Curious about latencies with bindings

  • I've added an automated test infrastructure to my app that is driven
    via a timer which fires every 100 ms.  Each time it fires an "opcode"
    is executed which does things like simulate a click on a button or
    set some property of a custom control.

    While everything works a-ok, I decided that since I was using a dual
    2GHz G5, that I'd experiment by pushing the limits of that timer :)

    Dropping the interval to 50 ms worked most of the time, but my script
    began to fail.  Take this particular run (script steps re-written as
    English pseudocode:)

    (1) enter in correct answer to math problem
    (2) validate the "correct" progress bar was incremented by one.

    What (1) does, among other things, is to increment the number of
    correct answers in my "Math Drill" model.  Step (2) simply queries
    the custom control as to its value (the control is bound to my
    model).  By having such a low interval, I'm seeing situations where
    the progress bar control has not yet been updated by the time the
    timer executes step (2).

    So, out of curiosity, am I running into latency issues with
    bindings?  Is there some way to sense that there are "pending
    updates"?  I really don't need the timer to run this fast; again,
    this was just an experiment to see how far I could push things.  But,
    if I could address these rare situations, my tests would all execute
    twice as fast :)

    ___________________________________________________________
    Ricky A. Sharp        mailto:<rsharp...>
    Instant Interactive(tm)  http://www.instantinteractive.com
  • On Jan 23, 2006, at 6:28 PM, Ricky Sharp wrote:

    > I've added an automated test infrastructure to my app that is driven
    > via a timer which fires every 100 ms.  Each time it fires an
    > "opcode" is executed which does things like simulate a click on a
    > button or set some property of a custom control.
    >
    > While everything works a-ok, I decided that since I was using a dual
    > 2GHz G5, that I'd experiment by pushing the limits of that timer :)
    >
    > Dropping the interval to 50 ms worked most of the time, but my
    > script began to fail.  Take this particular run (script steps re-
    > written as English pseudocode:)
    >
    > (1) enter in correct answer to math problem
    > (2) validate the "correct" progress bar was incremented by one.
    >
    > What (1) does, among other things, is to increment the number of
    > correct answers in my "Math Drill" model.  Step (2) simply queries
    > the custom control as to its value (the control is bound to my
    > model).  By having such a low interval, I'm seeing situations where
    > the progress bar control has not yet been updated by the time the
    > timer executes step (2).
    >
    > So, out of curiosity, am I running into latency issues with
    > bindings?  Is there some way to sense that there are "pending
    > updates"?  I really don't need the timer to run this fast; again,
    > this was just an experiment to see how far I could push things.
    > But, if I could address these rare situations, my tests would all
    > execute twice as fast :)

    Responding to myself here for the sake of the archives.

    After moving to an 8-core, my automated system would still fail in
    some situations.  The culprit was not latency in bindings, but in how
    I was simulating keyboard events (e.g. to enter a string of Unicode
    characters).

    What occurred was that for each separate character, I would post a
    keydown event.  And, depending upon how many characters were being
    posted, it could be the case where the next time the timer fired, it
    fired before all keyboard events were processed.

    All I needed to do was to make my key posting routine synchronous
    (basically polls/blocks until the event queue is void of keydowns).
    It is polling, but for each iteration, I call a blocking
    "nextEventInQueue" API that blocks for up to my timer's interval.

    Now all is well; I can crank down my timer interval to as low as 40
    ms.  When I get faster machines in the future, that number can be
    further lowered.
    ___________________________________________________________
    Ricky A. Sharp        mailto:<rsharp...>
    Instant Interactive(tm)  http://www.instantinteractive.com
previous month january 2006 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Go to today