Newline as a literal constant

Hi,

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().

Thanks,

create a global variable

CRLF=endofline.windows

and I doubt seriously if there is a performance hit using ENDOFLINE, as I will be the compiler resolves this to an internal constant anyways.

That’s a good thought about the compiler but I just did this simple test:

[code]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 100000
tmp = EndOfLine.Windows
next a
eolMethodTime = Microseconds - start

start = Microseconds
for a = 0 to 100000
tmp = EOL
next a
constantTime = Microseconds - start

break[/code]

and it looks like the constant method is ~5-6% faster…

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)

Just checked out the timing on my Mac, and the results are surprising:

2017r3:
EOLMethodTime: 14384
ConstantTime: 6398

2018r1.1:
EOLMethodTime: 29509
ConstantTime: 20698

for the record… I used 2016r4

It’s weird. Certainly seems like this would be an easy optimisation to make in the compiler. Maybe @Joe Ranieri knows why?

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

resultsArea.text = "eolMethodTime " + format(eolMethodTime, “0”) + chr(13) + "constantTime " + format(constantTime, “0”)[/code]

Numbers will be longer since I looped more times and had inline repetition, but you can see the relative differences.

2018 r1.1 Mac

IDE BackgroundTasks True
eolMethodTime 991554
constantTime  661879

IDE BackgroundTasks False
eolMethodTime 1166708
constantTime   750304

compiled 64bit BackgroundTasks True
eolMethodTime 395580
constantTime   42237

compiled 64bit BackgroundTasks False
eolMethodTime 378338
constantTime   28523

compiled 32bit BackgroundTasks True
eolMethodTime 758396
constantTime   69815

compiled 32bit BackgroundTasks False
eolMethodTime 704687
constantTime   44013

The constant version is obviously faster than calling a method.

IDE timings unsurprisingly longer than compiled, but what was a surprise is things being slower with BackgroundTasks disallowed in the IDE.

64 bit compiled version runs faster than the 32 bit compiled

Bear in mind that the 64-bit version is likely optimizing away the repeated code in your loop. 32-bit is doing a lot more work.

good point.
If that’s what’s happening between the 32 and 64 bit compiles, then it’s a plus for compiler optimization.

OK for the theory, but in a day to day word, how many times do you use Newline in your project(s) ?

What I want to highlight, it is insignificant if that feature is 0.00 slower than it can be.

Way more often that you might realize

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.