So the first thing to do when your well, actually, there are several things to do before this, when
you start to optimize, the first thing you should have is well tested code so that you know that when
you're optimizing, you're not breaking anything.
It's very important to have regression tests in your code.
I'm going to assume those are taken care of.
If they haven't been, you should write those first.
You should write a suite of tests that make sure that whatever you're changing doesn't break things.
After that, we want to set up benchmarks to actually test when things are getting faster versus, you
know, having them get slower or whatever.
This is a factual based investigation.
This is not about theories.
It's not about I think it's going to be faster if I use a vector instead of a list there.
This is something that you need to measure in order to make sure that you're getting consistently better
results.
Benchmarks are a tricky thing to get right.
Here's an example of a simple benchmarking thing.
This one uses current time, Melissa.
You can also use the nanosecond clock in that JVM if you want to use that current time is a bit later
to use.
So here's a loan, a loan method or a loan payment method called time.
It will take a name so we know what we're timing and then a function that returns some generic type.
And what we do at the beginning of this is we grab the system current time and Melis, we run the function
past, then it's a binding function, this path.
Then we get the elapsed time, which is the current time, minus the start time, and then we print
or log something that says this operation took this long and then we return.
The result.
Something to be really aware of here is that Scala on the JVM does not run directly on the machine that
runs on a on a virtual machine.
The JVM, to be specific, and the JVM itself has hot spot are just in time compiler that is over time
has become very polished and is able to do some incredible runtime optimizations, but it can vary.
So you want to make a few runs of things when you're doing benchmarks and in particular you want to
allow the JVM time to warm up and to perform its runtime optimizations.
Before you really start to believe those results, you may run something 10 or 20 times the same operation.
And what you're looking for is, you know, the later runs where everything is settled down, the JVM
has done its optimizations and it's running as fast as it can.