-
Notifications
You must be signed in to change notification settings - Fork 832
--reportTimeToFile:{path to csv} flag for fsc.exe writing out collected activities #14458
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
Conversation
|
Yeah, I think it's fine to redo what the old flag does, as long as it will have the same "functionality" - will allow to easily look at what times are spent where. |
|
Can you please share an example of what does file look like? |
That's good. It is not mentioned as part of --help and web documentation only says "Displays timing information for compilation.", which would be maintained. OK |
Yep, uploaded. |
|
Also - curious, if we enable GC and memory collection for any/all activities, will there be any impact to times at all. |
I would like to enable via a special/function call and by default only use it for measurements where the current code already did it anyway. Activity.start (and internally it would keep a well-known tag keyvaluepair with the GC data at start, then do the same at activity end, and print out the difference) |
--times : enables console reporting --times:<file> enables .csv reporting to a file Both these flags can be used at the same time
Co-authored-by: Petr Pokorny <[email protected]>
This PR introduced a new fsc.exe switch --reportTimeToFile: to write collected activities to a .csv file.
This functionality is exposed in a way that other users of FCS can use too ( = not restricted to fsc.exe):
To maintain a tabular structure of the .csv, only "well known" tag names are being exported.
This contains the main compilation phases (Parse > TypeCheck > ..) as well as gatherings for individual files.
As of now, the old functionality of "--times" remains intact (@vzarytovskii : Can we re-do what an existing flag does completely?), which means the code is still there.
If we could redo --times behavior (can be a separate PR for sure), we could:
The functionality can be exercised for a full build process on a project incl. it's dependencies like this:
Example of a produced file for multiple projects at once:
bigTestViaActivitySource.csv