Breaker Breaker

· Jan 22, 10:30 AM

The break statement tells the REALbasic debugger to pause program execution. But what does it do in non-debug applications?

According to the REALbasic language reference, “Break statements are ignored in standalone applications.” . But it turns out that this is not the case. Consider the following test methods.

Function TestNoBreak() as Double
  #pragma disableBackgroundTasks
 
  dim start as Double = Microseconds
  for i as Integer = 1 to 1000000
 
  next
  return Microseconds - start
End Function

Function TestBreak() as Double
  #pragma disableBackgroundTasks
 
  dim start as Double = Microseconds
  for i as Integer = 1 to 1000000
    break
  next
  return Microseconds - start
End Function

Running both methods in a build, I see that the second method takes about three times as long to execute as the first method. A little digging with Shark reveals the overhead of executing break in a compiled application.

A feedback report asking that break actually be a no-op in compiled applications has been submitted. Until then, break statements left in performance-sensitive code should be wrapped in pragmas.

#if debugBuild
  break
#endif

And now I am wanting to learn some assembly language…

---

Comment

  1. First off, the IDE lies to you – ‘break’ isn’t a statement, it’s a normal method (REALbasic.Break).

    Secondly, yes, calls to Break are left in your application. However, it does a very small amount of work. REALbasic.Break calls through to the runtime function RuntimeDebuggerBreak, which checks the value of a global variable (which is always zero in built apps), then exits. So you’re executing ~35 instructions for each call to REALbasic.Break. It’s quite insignificant compared to how unoptimized the rest of any RB app is.

    — Joe Ranieri · Jan 22, 12:24 PM · #

Commenting is closed for this article.