Can someone tell me why my application decreases in speed dramatically when I use:
If DoDebug = true Then logs(“DEBUG”,"…end of TS analyze phase; template: "+ str(Tmplt))
in stead of:
If DoDebug = true Then
logs(“DEBUG”,"…end of TS analyze phase; template: "+ str(Tmplt))
end if
I wanted to be able to debug where my Desktop application could go wrong and thought to do it with a one-liner, however the application became dramatically slow, DB selects took twice as long and when I changes all one-liners into the normally used ‘if…end if’ block the application was again as fast as it was before. Even when I DoDebug = False it was slow as syrup at 1 degrees Celsius just as when DoDebug = True.
I frankly do not know why it became so slow, but knowing and noticing this, I will not use these one-liners anymore…just tried it once now
Is there an explanation for this? I use Xojo2016r2 on Windows 10 (downloading Xojo2016r3 as speaking )
Jeff: DoDebug is a property set as boolean
Tim: I really don’t know what is going on. I only know that what I described above is what I experienced. When the if statement is on one line, the application became slow and the build up on the screen became slow.
I do read the database when I startup the app, that became slow too. Normally the splash screen is very short visible when the tool is started while the configuration, variables and data is read from the database I think about 1-2 seconds normally, but with the one line if statement it was visible for about 8-10 seconds. After I changed all single line if statements in the normally used if…then…end if block, the tool became as fast as before again.
Maybe someone else can try it to see if he/she experience the same?
In a one line If statement, does the whole thing actually get evaluated?
In other words, in a normal If statement, the rest of the block is only processed if the condition is true. But, contrary to what I’ve always understood and hoped, in a one-line If, does the rest of the line get prepared and examined in some manner but not executed, even if the condition is false?
Hopefully this isn’t the case but I can’t think what else would be going on here.
By the way, do you know there’s a built-in pragma?
[quote=288105:@Gavin Smith]In a one line If statement, does the whole thing actually get evaluated?
In other words, in a normal If statement, the rest of the block is only processed if the condition is true. But, contrary to what I’ve always understood and hoped, in a one-line If, does the rest of the line get prepared and examined in some manner but not executed, even if the condition is false?
Hopefully this isn’t the case but I can’t think what else would be going on here.
By the way, do you know there’s a built-in pragma?
#if debugBuild then
// Your code
#endif[/quote]
No, I didn’t know that. Does it show what and where something happened in the compiled code?
I don’t know the answer to your question nor have I experienced this myself, but you should avoid one-line If statements regardless. In this case, you are using it for debugging so it doesn’t much matter but in other cases, while debugging, it’s impossible to tell if the statement executed or not.
Tip: Once you start an IF statement (or any statement that requires a closing statement later like While, Do, etc.), you can press Shift-Return to end the statement.
Ok, thanks for the answer Kem. This was the first time I used an one-line IF statement. I normally use if…end if blocks. Think I was just being lazy lazy and then I observed this behaviour.
#if not DebugBuild
#pragma BackgroundTasks False
#pragma NilObjectChecking False
#pragma StackOverflowChecking False
#pragma BoundsChecking False
#endif
const kCount = 10000000
dim x as integer
dim msg as string
dim sw as new Stopwatch_MTC
sw.Reset
x = 0
sw.Start
for i as integer = 1 to kCount
if true then
x = x + 1
end if
next i
sw.Stop
msg = "Multi line: " + format( sw.ElapsedMicroseconds, "#," ) + " microsecs"
AddToResult msg
sw.Reset
x = 0
sw.Start
for i as integer = 1 to kCount
if true then x = x + 1
next i
sw.Stop
msg = "One line: " + format( sw.ElapsedMicroseconds, "#," ) + " microsecs"
AddToResult msg
IDE results:
Multi line: 589,343 microsecs
One line: 471,156 microsecs
Compiled 32-bit results:
Multi line: 21,029 microsecs
One line: 23,059 microsecs
I disagree. I use them all the time to make my code look cleaner and never had trouble with debugging.
If I’m debugging and realize I do need to know which way it switches (rare) then just add a CR and “end” to see; quick, mindless. Once debugged return it to one line so it looks tidy. Most of the time it’s just sitting there so I want it easy to scan.
Of course it looks tidy to me. Go with whatever causes the least effort in your brain.
How many times did you run it? I ran a similar test and hit the button several times. The results vary, sometimes 1 liners are faster, sometimes 3 liners. I think several rounds need to be run and look at the spread of times to really tell.
I’m still kind of curious why there is any difference at all. There must be some sort of evaluation of the entire line in a one-line if, regardless of the condition.
)