String___compare slow

[luboslenco]

We are gearing up our HL/C backend in Kha and I am already able run some Armory tests there. Running one of the tests, Visual Studio profiler reveals String___compare eats up 41% of CPU time (which gets spread into hl_value_to_string, hl_buffer_content, hl_alloc_obj). Compared to js/chakra, it appears to be at 1.3% there.

Do you think there is a way to speed up string comparison eventually? Let me know if I can help with more data. I am very excited about HL and happy to spend more time here to help make it faster.

[ncannasse]

Hi Lubos,

String.compare is supposed to be quite fast, see
https://github.com/HaxeFoundation/haxe/blob/development/std/hl/_std/String.hx#L185

It's right that we do a Dynamic check that could be avoided when we know at compilation time that the value is a string. Try disable this to see if it gets better (doing an unsafe cast instead)

[luboslenco]

Thanks for the pointer Nicolas. I hacked the __compare function like this:

@:keep function __compare( v : Dynamic ) : Int {
	// var s = Std.instance(v, String);
	// if( s == null )
		// return hl.Api.comparePointer(this, v);
	var s = cast(v, String); // <--
	var v = bytes.compare(0, s.bytes, 0, (length < s.length ? length : s.length) << 1);
	return v == 0 ? length - s.length : v;
}

And I am getting massive speed up. The particular test I am running gets from 17.3ms down to 3.3ms, which is a very good result. Would be super happy if this can be patched in master.

Robert is moving Kore to C and together with HL/C this is shaping up into an extremely competent environment for Kha projects. :)

[ncannasse]

We can't really remove this but I have analyzed the reason for slowdown and fixed it, requires a fresh haxe build ;)