Discussing the pros and cons of these text filtering strategies

In this third part of a four-part series, we’ll cover benchmarking in Go using our text filtering tools as a test topic. You can find the other parts below:

first, we Created a Go program to remove unwanted textAnd we Enhanced it with regular expression support, Now, we will learn about benchmarking in Go by comparing the initial substring search approach against paired regular expression pattern matching. Note that the methods used here are simple and intended to facilitate benchmarking discussions, not to objectively prove that one method is strictly faster than the other.

Go’s standard library test package Provides comprehensive testing support (you may have seen functions of the form TestXxx(t *testing.T)), as well as benchmarking support type b, B Provides the convenience of managing benchmark times, iterations, etc., as well as cleaning, logging, or failing tests on specific utility functions.

Using these tools, we can use substring or pattern matching to gain insight on whether the instrument runs faster (under these scenarios).

Go benchmarks are functions that run a . lives in <filename>_test.go file, where <filename> is usually the name of the file that contains the functions to be tested. Both files are usually in the same package, and the benchmark functions take the form of:

func BenchmarkXxx(b *testing.B) { // benchmark code }

When writing benchmarks, we usually need some code-specific initial setup and then move into a loop that will run the code under test multiple times (determined by the test package) Finally, we are told how many loops ran and how long each loop took (on average). From there, we can analyze the code performance.

We a. will start by installing []stringAlong a few lines of text — this would be typical for substring and pattern matching searches. then we’ll build a config which contains a set of either keys or a patternand then we’ll run lineMatches()(in a benchmark loop) in front of the input text and see how long each iteration takes. We’ll do this with varying amounts of keyphrase and pattern complexity (each made to match the same text) and compare the results.

Our benchmarks will be very simple: they will all use the same input text and generate a config either a. with keys or a pattern, We will create congruent substring search and pattern matching benchmarks for each query type. Then, we just need to run the test and compare the results.

We will use the following as our input test (e.g. in example/input.txt,