I know I can use EndOfLine() to get the UNIX and Windows style newline characters but is there a way to specify a literal constant for the Windows style (CR+LF) in the IDE? I know unicode literals can be declared with the &u prefix but does this work for two characters (char 13 and char 10)? I’m writing some very performance sensitive code and would like to avoid repeated method calls to EndOfLine().
Well I see a totally different set of metrics… now I AM running this under macOS not Windows, but it “should” be close to the same either way.
Running in the IDE, I see use of “constant” to be 2.25x FASTER (as in 225%)
compiles as a 32bit app, its 2.94x faster, but only 1.85x faster as a 64bit app (strange)
Or maybe not compiler optimization related. If a do recall how things work in Xojo, a Xojo app is an one real thread cooperative simulated multithreaded environment and framework, that in certain places, behind the scenes, calls internal things like CheckAndRunBackgroundThingsWeNeedToDo() and in the “starting new loop cycles” seems one of those points (While, For, Loop, etc). So, maybe 2018r1.1 could’ve NEEDED to have an increase of the “BackgroundThingsAndEventsToDo()” in between cycles, so it affects things like that. In preemptive scheduler environments, background “lags” would not occur consistently, because there were no hidden directly inserted tasks in the middle of the code, directly affecting time consumption by complexity and size of background tasks. If this is the case, maybe there’s nothing to do about it, as it must be necessary being as it is now.
I’m finding the constant definitely faster than a method call (which really isn’t that surprising given the overhead of a method call)
Did more inline and toggled backgroundTasks to minimize looping overhead and other tasks.
Ran in IDE and compiled 32 and 64 bits with backgroundTasks on/off
[code] #pragma BackgroundTasks false
dim tmp as String
dim a as Integer
dim start, eolMethodTime, constantTime as Double
dim EOL as String = EndOfLine.Windows
start = Microseconds
for a = 0 to 1000000
tmp = EndOfLine.Windows
tmp = EndOfLine.Windows
tmp = EndOfLine.Windows
tmp = EndOfLine.Windows
tmp = EndOfLine.Windows
tmp = EndOfLine.Windows
tmp = EndOfLine.Windows
tmp = EndOfLine.Windows
tmp = EndOfLine.Windows
tmp = EndOfLine.Windows
next a
eolMethodTime = Microseconds - start
start = Microseconds
for a = 0 to 1000000
tmp = EOL
tmp = EOL
tmp = EOL
tmp = EOL
tmp = EOL
tmp = EOL
tmp = EOL
tmp = EOL
tmp = EOL
tmp = EOL
next a
constantTime = Microseconds - start
When one method is more than 2x faster, and its in a process that might be parsing thousands (millions) of lines of text, it can be quite significant. If in fact it was a few seconds over millions of bytes of data, then I would opt for the most “readable” method, but if it is minutes (or worse), then optimize as best can be done.