Replies: 1 comment
-
|
Thanks for the investigation! I doubt it's the FST that's soaking up all of the memory. If anything, I would imagine it's the word map in the MutableDictionary, the trie in the |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hello! As an attempt to investigate why the plugin for Firefox has a high memory usage, I made the following git branch for testing purposes: https://github.com/ssvb/harper/commits/heaptrack/ with two commits. One commit introduces the use of the heaptrack tool, which is run in a github CI job on a simple
harper-cli lintinvocation. And another commit just erases almost all words from the English dictionary. Here are the results with the intact English dictionary:And this is after erasing all words from the English dictionary (except for "this", "is", "a", "test"):
It looks like the lion's share of the memory footprint is contributed by the dictionary. It's reported as ~130MB for
harper-cli(and ~170MB for the Firefox plugin) with a full dictionary, and merely ~8MB when the dictionary is stripped. Additionally, roughly ~400 milliseconds are added to the Harper's startup time on a rather powerful github CI machine to initialize the dictionary.These numbers look very suspicious to me. Because the FST data structure used for the dictionary is supposed to be much more compact: #138
Beta Was this translation helpful? Give feedback.
All reactions