ghcide/docs/opentelemetry.md
Pepe Iborra e24a744a06
Opentelemetry traces and heapsize memory analysis (#922)
* Move tracing functions to own module

* Bump opentelemetry to 0.6.0

* Write Values map size to OpenTelemetry metric

* Trace all requests and notifications

Instead of doing it in `HoverDefinition`, do it in
with{Response,Notification,...}. These wrap all handlers, so this should
cover everything. It also means that the span covers the entire
processing time for the request, where before we missed the setup
happening in the with* functions.

* Add flag for OpenTelemetry profiling

Run GC regularly with --ot-profiling

* Add flag to enable OT profiling in benchmark

* Use heapsize instead of ghc-datasize

I renamed the fork to distringuish from the original.
It is still being pulled from git using stack. This will be addressed
once I can push the fork to hackage.

* Bump opentelemetry to 0.6.1 - fixes 8.6 build

* Use heapsize from hackage

* Address HLint messages

* Record size of each key independently

* Refactor `startTelemetry` function

* Remove delay between measuring memory loops

* Each key in values map gets own OT instrument

* Measure values map length more rarely

* Rename --ot-profiling to --ot-memory-profiling

* Add docs for how to use the opentelemetry output

* Add instructions to build release version of tracy

* Clarify dependencies in opentelemetry instructions

* Fix LSP traces

* otTraced: delete unused

* Extract types out of D.IDE.Core.Shake

to avoid circular module dependencies

* Extract startTelemetry out of D.IDE.Shake and upgrade to 0.2

No more segfaults

* [nix] install opentelemetry

* [nix] install tracy

* Fix merge wibble

* Measure recursive sizes with sharing

* Sort keys for cost attribution

* Remove debug traces

* Allocate less, group keys, clean up hlints

* Add -A4G to the flags used for --ot-memory-profiling

* Modularize D.IDE.Core.Tracing

I want to reuse this code more directly in the non lsp driver

* Direct driver: report closure sizes when --ot-memory-profiling

An eventlog memory analysis doesnt' seem so relevant since this mode is not
interactive, but we could easily produce both if wanted to

* Everything is reachable from GhcSessionIO, so compute it last

I suspect the ShakeExtras record is reachable from GhcSessionIO

* bound recursion and use logger

* hlint suggestions

* Fix 8.6 build

* Format imports

* Do the memory analysis with full sharing. GhcSessionIO last

* Fail fast in the memory analysis

* error handling

* runHeapsize now takes initSize as an input argument

* Trace Shake sessions

* Reduced frequency for sampling values length

* Drop the -fexternal-interpreter flag in the Windows stack build

* Produce more benchmark artifacts

* Fix stack descriptors to use heapsize-0.2 from Hackage

* Bump to heapsize-0.3.0

* Record completions snippets (#900)

* Add field for RecordSnippets to CachcedCompletion

* Initial version of local record snippets

* Supprt record snippet completion for non local declarations.

* Better integration of local completions with current implementation

* Clean up non-local completions.

* Remove commented code.

* Switch from String to Text

* Remove ununsed definition

* Treat only Records and leave other defintions as is.

* Differentiate Records from Data constructors for external declaration

* Update test to include snippet in local record completions expected list.

* Update completionTest to also compare insertText.

* Add test for record snippet completion for imported records.

* Hlint fixes

* Hlint fixes

* Hlint suggestions.

* Update type.

* Consolidate imports

* Unpack tuple with explicit names

* Idiomatic changes

* Remove unused variable

* Better variable name

* Hlint suggestions

* Handle exhaustive pattern warning

* Add _ to snippet field name suggestions

* Remove type information passed around but not used

* Update to list comprehension style

* Eliminate intermediate function

* HLint suggestions.

* Idiomatic list comprehension

Co-authored-by: Pepe Iborra <pepeiborra@me.com>

* [nix] use gitignore.nix (#920)

* Ignore import list while producing completions (#919)

* Drop any items in explicit import list

* Test if imports not included in explicit list show up in completions

* Update README.md (#924)

* Custom cradle loading (#928)

When using ghcide as a library, it may be desirable to host the hie.yaml file
in a location other than the project root, or even avoid the file system altogether

* Favor `lookupPathToId` over `pathToId` (#926)

* Favor `lookupPathToId` over `pathToId`

* Fix `typecheckParentsAction`

* Fix `needsCompilationRule`

* Return completion snippets only when client supports it (#929)

* Use the real client capabilities on completions

* Return completion snippets only when supported by the client

Restored from https://github.com/haskell/ghcide/pull/900

* Redundant import

* Fix stack windows build

Co-authored-by: Michalis Pardalos <m.pardalos@gmail.com>
Co-authored-by: Michalis Pardalos <mpardalos@gmail.com>
Co-authored-by: Guru Devanla <gdevanla@users.noreply.github.com>
Co-authored-by: Samuel Ainsworth <skainsworth@gmail.com>
2020-12-05 17:44:17 +00:00

2.2 KiB

Using opentelemetry

ghcide has support for opentelemetry-based tracing. This allows for tracing the execution of the process, seeing when Shake rules fire and for how long they run, when LSP messages are received, and (currently WIP) measuring the memory occupancy of different objects in memory.

Capture opentlemetry data

Capturing of opentelemetry data can be enabled by first building ghcide with eventlog support:

stack build --ghc-options -eventlog

Then, you can run ghcide, giving it a file to dump eventlog information into.

ghcide +RTS -l -ol ghcide.eventlog -RTS

You can also optionally enable reporting detailed memory data with --ot-memory-profiling

ghcide --ot-memory-profiling +RTS -A4G -l -ol ghcide.eventlog -RTS

Note: This option, while functional, is extremely slow. You will notice this because the memory graph in the output will have datapoints spaced apart by a couple of minutes. The nursery must be big enough (-A1G or larger) or the measurements will self-abort.

Viewing with tracy

After installing opentelemetry-extra and tracy, you can view the opentelementry output:

eventlog-to-tracy ghcide.eventlog

If everything has been set up correctly, this should open a tracy window with the tracing data you captured

Installing opentelemetry-extra

This package includes a number of binaries for converting between the eventlog output and the formats that various opentelemetry viewers (like tracy) can display:

cabal install openetelemetry-extra

Building tracy

  1. Install the dependencies: pkg-config and glfw, freetype, capstone, GTK3, along with their header files (<pkgname>-dev on most distros. On Arch the header files are included with the normal packages).
  2. Download tracy from https://github.com/wolfpld/tracy
  3. cd into the directory containing the source you downloaded
  4. Build the import-chrome and Tracy libraries:
    make -C profiler/build/unix release
    make -C import-chrome/build/unix release
    
  5. Copy the binaries to your $PATH:
    cp profiler/build/unix/Tracy-release ~/.local/bin/Tracy
    cp import-chrome/build/unix/import-chrome-release ~/.local/bin/import-chrome