Add QueryPrinter for getting a string representation of a Query

[valencik]

Adds QueryPrinter to print out a string representation of a Query.

QueryPrinter.print(Proximity("cats jumped", 2))

"cats jumped"~2

Resolves #107

[valencik]

With the simple string concat printer

[info] Result "pink.cozydev.lucille.benchmarks.QueryPrinterBenchmark.termQueriesPrint":
[info]   1243.056 ±(99.9%) 72.279 ops/ms [Average]
[info]   (min, avg, max) = (1154.453, 1243.056, 1339.269), stdev = 83.236
[info]   CI (99.9%): [1170.778, 1315.335] (assumes normal distribution)
[info] # Run complete. Total time: 00:40:03
[info] REMEMBER: The numbers below are just data. To gain reusable insights, you need to follow up on
[info] why the numbers are the way they are. Use profilers (see -prof, -lprof), design factorial
[info] experiments, perform baseline and negative tests that provide experimental control, make sure
[info] the benchmarking environment is safe on JVM/OS/HW level, ask for reviews from the domain experts.
[info] Do not assume the numbers tell you what you want them to tell.
[info] Benchmark                               (size)   Mode  Cnt     Score    Error   Units
[info] QueryPrinterBenchmark.orQueriesPrint     10  thrpt   20  3211.063 ± 96.092  ops/ms
[info] QueryPrinterBenchmark.orQueriesPrint    100  thrpt   20   430.307 ±  1.827  ops/ms
[info] QueryPrinterBenchmark.orQueriesPrint   1000  thrpt   20    41.614 ±  0.097  ops/ms
[info] QueryPrinterBenchmark.termQueriesPrint   10  thrpt   20  1285.718 ±  7.069  ops/ms
[info] QueryPrinterBenchmark.termQueriesPrint  100  thrpt   20  1308.197 ± 11.859  ops/ms
[info] QueryPrinterBenchmark.termQueriesPrint 1000  thrpt   20  1243.056 ± 72.279  ops/ms
[success] Total time: 2406 s (40:06), completed Dec 19, 2023, 8:30:50 PM

[valencik]

Benchmarks with the StringBuilder approach and also just calling .toString() on the Query case class as a sort of baseline:

[info] Benchmark                                       (size)   Mode  Cnt     Score     Error   Units
[info] QueryPrinterBenchmark.orQueriesPrint                10  thrpt   20  4913.727 ±  94.479  ops/ms
[info] QueryPrinterBenchmark.orQueriesPrint               100  thrpt   20   555.244 ±  19.572  ops/ms
[info] QueryPrinterBenchmark.orQueriesPrint              1000  thrpt   20    58.698 ±   0.279  ops/ms
[info] QueryPrinterBenchmark.orQueriesPrintOld             10  thrpt   20  3176.977 ±  85.412  ops/ms
[info] QueryPrinterBenchmark.orQueriesPrintOld            100  thrpt   20   430.566 ±   3.422  ops/ms
[info] QueryPrinterBenchmark.orQueriesPrintOld           1000  thrpt   20    41.384 ±   0.404  ops/ms
[info] QueryPrinterBenchmark.orQueriesPrintToString        10  thrpt   20  1077.642 ± 102.904  ops/ms
[info] QueryPrinterBenchmark.orQueriesPrintToString       100  thrpt   20   192.621 ±  28.387  ops/ms
[info] QueryPrinterBenchmark.orQueriesPrintToString      1000  thrpt   20    19.669 ±   2.172  ops/ms
[info] QueryPrinterBenchmark.termQueriesPrint              10  thrpt   20  1280.688 ±   6.515  ops/ms
[info] QueryPrinterBenchmark.termQueriesPrint             100  thrpt   20  1260.382 ±   9.133  ops/ms
[info] QueryPrinterBenchmark.termQueriesPrint            1000  thrpt   20  1255.772 ±  10.110  ops/ms
[info] QueryPrinterBenchmark.termQueriesPrintOld           10  thrpt   20  1243.494 ±  15.798  ops/ms
[info] QueryPrinterBenchmark.termQueriesPrintOld          100  thrpt   20  1222.824 ±  34.379  ops/ms
[info] QueryPrinterBenchmark.termQueriesPrintOld         1000  thrpt   20  1263.705 ±  17.696  ops/ms
[info] QueryPrinterBenchmark.termQueriesPrintToString      10  thrpt   20   680.583 ±   9.988  ops/ms
[info] QueryPrinterBenchmark.termQueriesPrintToString     100  thrpt   20   634.705 ±   9.397  ops/ms
[info] QueryPrinterBenchmark.termQueriesPrintToString    1000  thrpt   20   674.105 ±  17.697  ops/ms

These are in operations per second, so higher is better.
The Stringbuilder approach seems about 1.3-1.5 times faster than the string concatenation approach, an 3-4x fast that toString().
That the performance gap isn't larger makes sense, the string concatenation approach still leverages StringBuilders inside all the mkString calls.

[valencik]

I had been hesitant to call this "done" because it doesn't expose any configuration, in particular whether or not the printer should force in OR delimiters.

For example we parse the following query: cat hat and then print it back out as cat OR hat.

However, we also don't expose any configuration on the parsing side to explicitly say the default boolean (OR vs AND). So adding this in this PR would be a bit of work.

We should offer this configuration at some point, but perhaps it's better in another PR.
I think this PR is ready to go in its current scope.

[samspills]

unrelated aside: do we need to update this?

[samspills]

However, we also don't expose any configuration on the parsing side to explicitly say the default boolean (OR vs AND). So adding this in this PR would be a bit of work.
We should offer this configuration at some point, but perhaps it's better in another PR.

I agree about offering the configuration, and agree that work is worth it's own PR

[samspills]

I did not run the benchmarks, just fyi

[samspills]

😎