Want your Go programs to run faster? Optimizing string comparisons in Go can improve your application’s response time and help scalability. Comparing two strings to see if they’re equal takes processing power, but not all comparisons are the same. In a previous article, we looked at and did some benchmarking. We’re going to expand on that here. How to compare strings in Go It may seem like a small thing, but as all great optimizers know, it’s the little things that add up. Let’s dig in. Measuring Case Sensitive Compares First, let’s measure two types of string comparisons. Method 1: Using Comparison Operators a == b { } { } if return true else return false Method 2: Using Strings.Compare strings.Compare(a, b) == { } if 0 return true return false So we know the first method is a bit easier. We don’t need to bring in any packages from the standard library, and it’s a bit less code. Fair enough, but which one is faster? Let’s find out. Initially, we’re going to set up a single app with a test file. We’re going to use the Benchmarking utility from the Go test tools. compare.go main ( ) {
} { a == b { } { }
} { strings.Compare(a, b) == { } package import "strings" func main () // operator compare func compareOperators (a , b ) string string bool if return true else return false // strings compare func compareString (a , b ) string string bool if 0 return true return false And we’ll create a set of tests for it: compare_test.go main ( ) { n := ; n < b.N; n++ {
		compareOperators( , )
	}
} { n := ; n < b.N; n++ {
		compareString( , )
	}
} package import "testing" func BenchmarkCompareOperators (b *testing.B) for 0 "This is a string" "This is a strinG" func BenchmarkCompareString (b *testing.B) for 0 "This is a string" "This is a strinG" For the string samples, I will change the last character to make sure the methods parse the entire string. Some notes if you’ve never done this: We are using the By naming it Go knows to look for tests here. Instead of tests, we insert benchmarks. Each func must be preceded by We will run our tests with bench flag Go testing package compare_test.go Benchmark. To run our benchmarks, use this command: go -bench=. test Here are my results: So using standard comparison operators is faster than using the method from the Strings package. 7.39 nanoseconds vs. 2.92. Running the test several times shows similar results: So, it’s clearly faster. 5ms can make a big difference at a large enough scale. Verdict: Basic string comparison is faster than strings package comparison for case sensitive string compares. Measuring Case Insensitive Compares Let’s change it up. Generally, when I’m doing a string compare, I want to see if the test in the string matches, no matter which characters are capitalized. This adds some complexity to our operation. sampleString := compareString := "This is a sample string" "this is a sample string" With a standard compare, these two strings are not equal because the T is capitalized. However, we are now looking for the text, and don’t care how it’s capitalized. So let’s change our functions to reflect this: { strings.ToLower(a) == strings.ToLower(b) { } } { strings.Compare(strings.ToLower(a), strings.ToLower(b)) == { } } // operator compare func compareOperators (a , b ) string string bool if return true return false // strings compare func compareString (a , b ) string string bool if 0 return true return false Now before each comparison, we make both strings lowercase. We’re adding in some extra cycles to be sure. Let’s benchmark them. They appear to be the same. I run it a few times to be sure: Yep, they’re the same. But why? One reason is, we’ve added the action to every execution. This is a performance hit. Remember strings are simple runes, and the ToLower() method loops through the rune, making every character lowercase, then performs a comparison. This extra time washes out any big differences between the actions. Strings.ToLower Introducing EqualFold In our last article, we looked at EqualFold as another way of doing case insensitive compares. We determined Equalfold was the fastest of the three methods. Let’s see if this set of benchmark reflects that. Add this to compare.go { strings.EqualFold(sampleString, compareString) { } { }
} // EqualFold compare func compareEF (a , b ) string string bool if return true else return false And add the following test to compare_test.go { n := ; n < b.N; n++ {
		compareEF( , )
	}
} func BenchmarkEqualFold (b *testing.B) for 0 "This is a string" "This is a strinG" So lets now run a benchmark on these three methods: Wow! EqualFold is considerably faster. I run it several times with the same results. Why is it faster? BecauseEqualfold also parses the rune character by character, but it “drops off early” when it finds a different character. Verdict: EqualFold (Strings Package) comparison is faster for case sensitive string compares. Let’s Ramp Up Our testing Ok, so we know these benchmarks show significant differences between the methods. Let’s add in some more complexity, shall we? In the last article, we added in this to make comparisons. We’ll change our methods to open up this file and run string comparisons till we find a match. 200,000 line word list In this file, I added the name we’re searching for at the of the file, so we know the test will loop through 199,000 words before matching. end Change your methods to look like this: compare.go {
	file, err := os.Open( )
	result := ; err != {
		log.Fatalf( , err)
	}

	scanner := bufio.NewScanner(file)
	scanner.Split(bufio.ScanLines) scanner.Scan() { strings.ToLower(a) == strings.ToLower(scanner.Text()) {
			result = } {
			result = }
	}
	file.Close() result
} {
	file, err := os.Open( )
	result := ; err != {
		log.Fatalf( , err)
	}

	scanner := bufio.NewScanner(file)
	scanner.Split(bufio.ScanLines) scanner.Scan() { strings.Compare(strings.ToLower(a), strings.ToLower(scanner.Text())) == {
			result = } {
			result = }
	}
	file.Close() result
} {
	file, err := os.Open( )
	result := ; err != {
		log.Fatalf( , err)
	}

	scanner := bufio.NewScanner(file)
	scanner.Split(bufio.ScanLines) scanner.Scan() { strings.EqualFold(a, scanner.Text()) {
			result = } {
			result = }
	}
	file.Close() result
} // operator compare func compareOperators (a ) string bool "names.txt" false if nil "failed opening file: %s" for if true else false return // strings compare func compareString (a ) string bool "names.txt" false if nil "failed opening file: %s" for if 0 true else false return // EqualFold compare func compareEF (a ) string bool "names.txt" false if nil "failed opening file: %s" for if true else false return Yes, each of these are now going to: Open a text file Parse it line by line Look for the search phrase Let’s change our tests now, so the funcs only take one parameter: compare_test.go { n := ; n < b.N; n++ {
		compareOperators( )
	}
} { n := ; n < b.N; n++ {
		compareString( )
	}
} { n := ; n < b.N; n++ {
		compareEF( )
	}
} func BenchmarkCompareOperators (b *testing.B) for 0 "Immanuel1234" func BenchmarkCompareString (b *testing.B) for 0 "Immanuel1234" func BenchmarkEqualFold (b *testing.B) for 0 "Immanuel1234" So now, we can expect the test to take longer, so there will be fewer iterations from the benchmarking tool. Let’s run it: And EqualFold still comes out on top, by quite a bit. Adding to the complexity of this test is good and bad. : Reading in text and doing sequential tests is more “real life” simulation Good : We can force more diverse testing with different strings Good : We introduce several factors (file reading, etc.) that could skew our results. Bad Verdict: EqualFold (Strings Package) comparison is STILL faster for case sensitive string compares. But Wait, There’s More!! Is there any way we can make this compare even faster? Of course. I decided to try counting the characters of the string. If the character count is different, it’s not the same string, so we can “duck out early” on the comparison altogether. But we still need to include EqualFold in case the strings are equal length but different characters. The added check of the count makes the operation more expensive, so would it be faster? Let’s find out. compare.go {
	file, err := os.Open( )
	result := ; err != {
		log.Fatalf( , err)
	}

	scanner := bufio.NewScanner(file)
	scanner.Split(bufio.ScanLines) scanner.Scan() { (a) == (scanner.Text()) &&  strings.EqualFold(a, scanner.Text()){
			result = } {
			result = }
	}
	file.Close() result
} func compareByCount (a ) string bool "names.txt" false if nil "failed opening file: %s" for if len len true else false return compare_test.go { n := ; n < b.N; n++ {
		compareByCount( )
	}
} func BenchmarkCompareByCount (b *testing.B) for 0 "Immanuel1234" And it is indeed faster! Every little bit counts. Verdict: Do a character count with your EqualFold comparison for even more speed Summary In this article, we looked at a few different string comparison methods and which one is faster. Bottom line: Use a basic comparison for case sensitive comparisons, and character count + EqualFold for case insensitive comparisons. I love doing tests like this, and you’ll find small changes add up pretty nice when you’re doing optimization. Stay tuned for more articles where we look at optimizations like this. What do you think? Let me know! Previously published at https://www.jeremymorgan.com/blog/golang/optimizing-string-compare-go/

Different

Winner of Noonies 2020 for the award Hacker Noon Contributor of the Year - LINUX.

2020 - Hacker Noon Contributor of the Year in LINUX

2022 - HackerNoon Contributor of the Year - Azure

2022 - HackerNoon Contributor of the Year - Dotnet

2022 - HackerNoon Contributor of the Year - Functional Programming

Follow me! 

Nominated for 2022 - HackerNoon Contributor of the Year - Functional Programming

Nominated for 2022 - HackerNoon Contributor of the Year - Dotnet

Nominated for 2022 - HackerNoon Contributor of the Year - Azure

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

Optimizing String Comparisons in Go

Too Long; Didn't Read

Companies Mentioned

jeremymorgan

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Optimizing String Comparisons in Go

Too Long; Didn't Read

Companies Mentioned

jeremymorgan

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES