-
Notifications
You must be signed in to change notification settings - Fork 154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reducing memory allocations for file path maths #1139
Conversation
15c9893
to
56c9c90
Compare
f4c2410
to
b09e1aa
Compare
// fsLogger.debug ( | ||
// Log.setMessage "{path} expanded to {expanded}" | ||
// >> Log.addContext "path" f | ||
// >> Log.addContext "expanded" expanded | ||
// ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These logging functions can get called a lot and do actually allocate so commented out for now.
We'll work on some lower allocation solution later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let inline debug a b c = ()
let foo () =
debug 1 (2+2) 4
it seems the compiler is optimizing this, wondering if this can be used to make the debug function a no-op in release builds while keeping the code around for debug builds?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess no:
let inline debug a b c = ()
let foo () =
debug (new obj()) (new obj()) (new obj())
it doesn't get elided.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could always ifdef them i guess
3b14e1b
to
2717429
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WHAT
🤖 Generated by Copilot at 3612b5b
This pull request updates the
FSharp.Compiler.Service
library and introduces some performance and robustness improvements to the FsAutoComplete project. It removes some obsolete code, adds some error logging, optimizes some string and buffer operations, and enhances the language server protocol communication. It also adds two new NuGet packages:LinkDotNet.StringBuilder
andCommunityToolkit.HighPerformance
. It includes an unrelated change to theplayground.fsx
file that may need to be removed or explained.🤖 Generated by Copilot at 3612b5b
🚀🐛🧹
WHY
These get called all the time, even while scrolling. While it's not a ton of savings compared to toher calls, it adds up. Didn't get rid of the URI LocalPath allocation because that's way to much work while this was a relatively simple switch to spans.
HOW
🤖 Generated by Copilot at 3612b5b
TryGetRecentCheckResultsForFile
method (link)LinkDotNet.StringBuilder
andCommunityToolkit.HighPerformance
packages to improve performance and memory efficiency (link, link, link)ReadOnlySpan<char>
andValueStringBuilder
types to avoid string allocations and optimize path and uri manipulation inUtils.fs
(link, link, link, link)SpanOwner
type to manage memory buffers inAdaptiveFSharpLspServer.fs
(link)ThrottleBy
extension method to group and delay analyzer execution inAdaptiveFSharpLspServer.fs
(link)parseAndCheckFile
function inAdaptiveFSharpLspServer.fs
(link)forceGetTypeCheckResultsStale
function inAdaptiveFSharpLspServer.fs
(link)handleCommandEvents
function inAdaptiveFSharpLspServer.fs
(link)FileSystem.fs
to reduce verbosity and string allocations (link, link)playground.fsx
for testing custom computation expression builder (link)