Speed up StringTools.(starts|ends)With on Lua

[sebthom]

With this PR applied StringTools.startsWith is 10 times faster and StringTools.endsWith is 6 times faster on Lua.

It is also faster than using lua.NativeStringTools.sub which instantiates - in this case unnecessary - temporary @:multiReturn objects.

[Simn]

Shouldn't we have a way of calling this sub-function without using untyped? I thought this was what NativeStringTools.sub did, but I guess there's something else going on.

[sebthom]

As I mentioned in the description, using the NativeStringTools comes with a performance penalty (I suspect because of the emulated @:multiReturn handling). In my tests the overhead was up to 100%.

[Simn]

Yes I read that this is your observation, my question is why that is the case. If using untyped __lua__ is superior to a properly typed extern then we're having a larger problem to consider.

But I'm not very familiar with lua, so I can't really estimate the effort to address this "properly". If you say that this is at least a pragmatic approach then I'm happy to merge it.

[sebthom]

I cannot really answer the question why it is faster using the untyped version.

Anyways, I replaced it with NativeStringTools.sub for now to avoid any confusion. This still is a win as it also is considerably (9 times) faster than the current implementation.

[Simn]

I'm seeing this:

results: SOME TESTS FAILURES (success: false)
unit.issues.Issue8211
  test: FAILURE .FF
    line: 6, expected true
    line: 7, expected true

[sebthom]

I will look into it

[sebthom]

apparently it does not work when using NativeStringTools.sub because we pass searchString.length to it which is not unicode aware. However bypassing NativeStringTools and relying on Lua to directly figure out the length of the search string using the lua operator # works. So one more reason to use the first approach. It is even faster and also works with unicode strings. I am going to change the PR again

[sebthom]

@Simn, tests are green now.

[Simn]

Hmpf, I'm very reluctant to add something involving untyped to std in 2023... At the very least we should have something like Syntax.code for lua, but we can look into that as part of another issue.