What useful information can I extract from F # interactive weekend times?
While learning F #, sometimes I write several variants of the algorithm (with the same asymptotic complexity) for fun. But in the end, I also want to get some idea of what I want to keep using or improving.
So, I am using F # interactive with the command #time
. The obvious criterion for making a decision is, of course, the time it takes to complete some tasks. But I am getting additional information that I suspect is related to garbage collection statistics. But I don't know what to do about it.
Here are some timing examples for the three permutation algorithms:
> let len = 10
> let last _ = // some way of knowing all have been seen (i.e. counting)
> let a = [|1..len|]
> a |> grayPermutations |> Seq.find last |> printfn "%A"
> [|2; 1; 3; 4; 5; 6; 7; 8; 9; 10|]
Real: 00:00:13.323, CPU: 00:00:13.343, GC gen0: 763, gen1: 762, gen2: 1
> a |> permutations |> Seq.find last |> printfn "%A"
> [|10; 9; 8; 7; 6; 5; 4; 3; 2; 1|]
Real: 00:00:00.631, CPU: 00:00:00.625, GC gen0: 138, gen1: 138, gen2: 0
> a |> findPermutation last |> printfn "%A"
> [|10; 1; 2; 3; 4; 5; 6; 7; 8; 9|]
Real: 00:00:04.400, CPU: 00:00:04.390, GC gen0: 385, gen1: 385, gen2: 0
The winner is pretty clear, but what does the material say after the timings? And can (or should) try to optimize for this - something I know what that means?
source to share
The output of the directive #time
outputs information about real time, cpu time and garbage collection, where you can see the number of garbage collection operations in all three generations of the managed heap
Generation 0 . It is the youngest generation and contains short-lived objects. An example of a short-lived object is a temporary variable. Garbage collection occurs most often in this generation. Newly allocated objects form a new generation of objects and implicitly generate 0 collections unless they are large objects, in which case they go into the big object heap in generation 2. Most objects are reclaimed for collection garbage in generation 0 and don't survive until the next generation.
Generation 1 . This generation contains short-lived objects and serves as a buffer between short-lived objects and long-lived objects.
Generation 2 . This generation contains long-lived objects. An example of a long-lived object is an object in a server application that contains static data that lives during a process.
On the other hand, evaluating algorithms strictly at runtime is flawed as you can have one approach that runs in O (n) time and another that runs in O (n2), but the difference between the two only shows up for large inputs ...
source to share