Fcs profiling util #2312
Fcs profiling util #2312
Conversation
|
This is one of subsequent checking:
The memory at the peaks is a little bit higher than 1GB. |
|
Hmm, cannot reproduce 0:52 result for first run anymore :( 3:04 now... |
* change target framework (so can build with vs2015) * change to x86 * add <W> and <M> keys to waste some memory (loads 100mb array and put it in a resizearray) or reclaim waste (clear the resizearray) for extra memory pressure
minor changes to LanguageServiceProfiling:
This reverts commit 82aefda.
| printfn "ParseAndCheckFileInProject(%s)..." relativePath | ||
| let filePath = Path.Combine(rootDir, relativePath) | ||
| let sw = Stopwatch.StartNew() | ||
| let _, answer = checker.ParseAndCheckFileInProject(filePath, fileVersion, File.ReadAllText filePath, options) |> Async.RunSynchronously |
There was a problem hiding this comment.
Would be great to add some options to perform some GetDeclarations, GetToolTip calls and the FCS calls needed to support find-all-references
|
@vasily-kirichenko Super work, a great start towards getting a firmer grip on memory usage. |
make the M/W keys actually more useful
added a crude call to GetDeclarationListInfo
|
This is fantastic - I know it's something that Don's been keen to see for a while based on his GH comments. This would be really useful to put into CI if there's a way to automate it too - it would be useful to know that some of the core FCS functions are not increasing in memory usage and we can finally reproducibly quantify this resource consumption. Great job 🥇 |
|
Not related to this utility, but in a large solution (with only a handful of F# projects), having F# projects with large number of assembly references (from 3rd part vendors), ILBinaryReader.ILReaderContext seems to be high in the list.
(this is VS2015 and I have VFPT installed) My guess is that it is common industry usage to have F# projects with a significant amount of dependencies, it might be worth to look at the memory occupied by the assembly reader and see if there aren't some obvious gains pending there. Ideally that should be shared with representation used by C#/VB.NET projects (understanding that some extra structures are necessary for specificities of each language) as I'm using the same assembly references in many projects. |
| @@ -114,6 +114,17 @@ type internal ProjectInfoManager | |||
| member this.UpdateProjectInfo(projectId: ProjectId, site: IProjectSite, workspace: Workspace) = | |||
| let extraProjectInfo = Some(box workspace) | |||
| let options = ProjectSitesAndFiles.GetProjectOptionsForProjectSite(site, site.ProjectFileName(), extraProjectInfo, serviceProvider) | |||
|
|
|||
| //lock this <| fun _ -> | |||
There was a problem hiding this comment.
@vasily-kirichenko
Could we have a comment describing why this code is commented out. It is fair to say that we all know why it is commented out right now ... but in the future we may have forgotten.
We could also consider using the preprocessor to disable it rather than using comments too.
change LanguageServiceProfiling util target framework to 4.6
|
Thank you |
This utility console does the following:
<C>:ParseAndCheckProjectfro FSharp.Compiler.Service project (not the similar one from this repo, but the other one, from FCS NuGet is built)<G>: GC.Collect(2)usage:
LanguageServiceProfiling <path to FSharp.Compiler.Server repository>I've failed to use or port FSharpProjectCracker, so I logged
FSharpProjectOptionsright in running VS and copy it intoOptions.fsfile.Interesting things so far:
NameResolution.fs) - 3:42 (!)