Skip to content

High transcient STACK usage #4976

Description

@guibou

I've recently started HLS with +RTS -l -hT and did a "simple" editing session (where I mostly opened a few file, did some import insert and delete and roughly forget about the editor for a few hours.

The resultnig eventlog is interesting. It shows burst of STACK memory usage.

Image

If I only zoom on the STACK, we can see that the burst is up to 1.2GiB which is close to 100% of the memory used at that time:

Image

Said otherwise: STACK burst close to DOUBLE the peak memory usage.

I'm opening this issue to document my findings, I'll do more investigation in the following days.

Except in rare occurrence, STACK should not grow so large like that, so there may be a really low hanging fruit to harvest here.

Your environment

Which OS do you use? Nixos
Which version of GHC do you use and how did you install it?
9.14.1, installed from nix, with some patchs. I don't think that's relevant here because I had not observed huge increase of HLS memory usage since a while, so this problem may be there since a long time (I'm use to kill HLS a few time per week because of out of memory, if something had doubled the memory usage of HLS in my latest GHC update, I would have noticed it immediatly ;)
How is your project built (alternative: link to the project)? Custom nix build system.

Which LSP client (editor/plugin) do you use? Neovim
Which version of HLS do you use and how did you install it? some commit from 2.14.0.0 branch (actually, #4600 + some additionnal company changes)

Have you configured HLS in any way (especially: a hie.yaml file)?

Steps to reproduce

On a large project, run hls with +RTS -hT -l, do an editing session and see the .eventlog file created in the directory, then convert that with eventlog2html. (You may have to disable the "event" and be careful, if you use hls on nix for example, the file can be hidden because named .haskell-language-server....eventlog.

Expected behaviour

Less STACK (this is a NOT a build system discussion)

Actual behaviour

Too much STACK

Debug information

edit: I tried to clarify that I'm talking about stack usage: e.g. how much memory is retained at a point in time in STACK, not "allocation", because allocating STACK would be perfectly acceptable if it was garbage collected immediatly.

Metadata

Metadata

Assignees

No one assigned

    Labels

    performanceIssues about memory consumption, responsiveness, etc.type: bugSomething isn't right: doesn't work as intended, documentation is missing/outdated, etc..

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions