It's important to use `Release` if you want to see if your changes have had a noticeable performance impact.
### Performance and debugging
Use the `Debug` configuration to test your changes locally. It is the default. Do not use the `Release` configuration! Local development and testing of Visual Studio tooling is not designed for the `Release` configuration.
### Troubleshooting a failed build of the tools
You may run into an issue with a somewhat difficult or cryptic error message, like:
...
...
@@ -188,6 +191,165 @@ To fix this, delete these folders:
Where `<version>` corresponds to the latest Visual Studio version on your machine.
## Performance and debugging
Use the `Debug` configuration to test your changes locally. It is the default. Do not use the `Release` configuration! Local development and testing of Visual Studio tooling is not designed for the `Release` configuration.
### Writing and running benchmarks
Existing compiler benchmarks can be found in `tests\benchmarks\`.
### Benchmarking and profiling the compiler
**NOTE:** When running benchmarks or profiling compiler, and comparing results with upstream version, make sure:
* Always build both versions of compiler/FCS from source and not use pre-built binaries from SDK (SDK binaries are crossgen'd, which can affect performance).
* To run `Release` build of compiler/FCS.
### Example benchmark setup using [BenchmarkDotNet](https://github.com/dotnet/BenchmarkDotNet)
1. Perform a clean build of the compiler and FCS from source (as described in this document, build can be done with `-noVisualStudio` in case if FCS/FSharp.Core is being benchmarked/profiled).
2. Create a benchmark project (in this example, the project will be created in `tests\benchmarks\`).
```shell
cd tests\benchmarks
dotnet new console -o FcsBench --name FcsBench -lang F#
> For more detailed information about available BenchmarkDotNet options, please refer to [BenchmarkDotNet Documentation](https://benchmarkdotnet.org/articles/overview.html).
6. Build and run the benchmark.
```shell
dotnet build -c Release
dotnet run -c Release
```
7. You can find results in `.\BenchmarkDotNet.Artifacts\results\` in the current benchmark project directory.
| ParsingTypeCheckerFs | 199.4 ms | 3.84 ms | 9.78 ms | 195.5 ms | 4000.0000 | 1000.0000 | 28 MB |
8. Repeat for any number of changes you would like to test.
9.**Optionally:** benchmark code and results can be included as part of the PR for future reference.
## Additional resources
The primary technical guide to the core compiler code is [The F# Compiler Technical Guide](https://github.com/dotnet/fsharp/blob/main/docs/index.md). Please read and contribute to that guide.
(Error965,Line11,Col1,Line11,Col22,"The path 'System.IO' is a namespace. A module abbreviation may not abbreviate a namespace.")
(Error39,Line13,Col15,Line13,Col17,"The value, namespace, type or module 'IO' is not defined.")
(Error965,Line16,Col1,Line16,Col43,"The path 'System.Text.RegularExpressions' is a namespace. A module abbreviation may not abbreviate a namespace.")
(Error39,Line18,Col19,Line18,Col21,"The namespace or module 'rx' is not defined.")
(Error72,Line21,Col4,Line21,Col19,"Lookup on object of indeterminate type based on information prior to this program point. A type annotation may be needed prior to this program point to constrain the type of the object. This may allow the lookup to be resolved.")
(Error10,Line5,Col11,Line5,Col12,"Unexpected symbol '$' in definition. Expected incomplete structured construct at or before this point or other token.")
