Dynamic type lookup string compare optimization

[ladd]

This is a small optimization for a specific path of dynamic type lookup, as profiled below in our iOS application. In a small synthetic benchmark, using strncmp is roughly twice as fast as using strlen + memcmp via StringRef in the case where the two mangled type strings match.

(missing frames due to inlining?)

Other ideas for optimizing this path welcome!

[mikeash]

@swift-ci please benchmark

[ladd]

Seems to be within the noise, if I'm understanding the report. Does this need a smoke test as well? (I don't have commit access)

[mikeash]

Yeah, looks like no measurable difference (no surprise there) but still seems worth doing. I'll go ahead and run a full test.

[mikeash]

@swift-ci please test

[ladd]

Thanks for running the tests. Anything else to do here?

[jckarter]

If this is a real win, it might be nice to upstream it to LLVM as an additional overload for StringRef::equals, so that all uses of StringRef::equals with a C string argument in the compiler and runtime benefit.

[jckarter]

It's a bit unfortunate to have to iterate through s2 twice here. What does performance look like if we use an inline loop here instead of strncmp to do the entire comparison in one pass? It'd be interesting to see if strncmp and/or strlen are optimized enough to offset the double iteration through s2 compared to a loop that precisely accounted for s1's fixed length and s2's null termination in one pass.

[ladd]

A naive inline loop seems to be ≈3x slower than platform strncmp in my tests with a 65 byte long sample string. I suspect this is due to the optimized ARM assembly implementations in llvm-project/libc/AOR_v20.02/string/aarch64 + the compiler's optimization of built-ins. That said, my assembly skills are a bit rusty.

I tried something like this with -O3:

inline static bool testcmp(const char *left, const char *right, size_t n) {
	for (int i=0; i < n; i++) {
		char lc = left[i];
		char rc = right[i];
		
		if (lc != rc || rc == '\0') {
			return false;
		}
	}
	return true;
}

[jckarter]

In that case, it looks good as is. Thanks for trying it out!

[ladd]

No worries -- at this level of the code, I think you could only do better if you already knew the length of s2, or knew that s1 contained no embedded NUL characters.

[mikeash]

@jckarter Are you good with merging now? Getting it into LLVM sounds nice but as a separate thing.

[jckarter]

@mikeash Yeah, I'm fine merging this now.