Skip to content

Conversation

@jasonmalinowski
Copy link
Member

While looking at our existing logging code to figure out what I can reuse, I noticed a few bits that could use some cleanup. Changes:

  1. Pass around TimeSpans instead of ints for time; this avoids some confusion around units (especially when called "ticks" since that term is ambiguous between different units)
  2. Make the types that are implicitly keyed by something generic, so the type of key is clear.
  3. Rename LogAggregator to CountLogAggregator, so that way the naming matches its sibling types in the type hierarchy.
  4. Move some helpers out of the abstract generic class that don't need to be there.

Commit at a time may or may not help; on one hand each change is pretty mechanical, but the same pieces of code may get touched by multiple commits so that might increase the total amount of code to read pretty significantly.

@ghost ghost added the Area-IDE label Jun 27, 2022
@jasonmalinowski
Copy link
Member Author

jasonmalinowski commented Jun 27, 2022

This is a recreation of #61669 that was reverted due to a regression. After some investigation, we believe the regression is just due to a lack of updated training data for ngen, and the correct process is just to merge this and let training catch up.

@jasonmalinowski jasonmalinowski self-assigned this Jun 28, 2022
We (mostly) use these to track time, but rather than just letting
them directly take a TimeSpan, we were expecting each of the callers
to distill it down to milliseconds and the pass it as an integer.
This actually clarifies a current surprise that some of our code
calls the data points "ticks" but they're actually logging milliseconds,
but that wasn't obvious since there were just ints being passed around
everywhere.

Even for the cases we were passing around milliseconds, what we were
often doing is taking a TimeSpan, grabbing it's TotalMilliseconds and
then:

- casting it to an int to pass around to our logging functions
- casting that to a decimal to pass to the log aggregators
- doing decimal division to figure out which bucket it goes in
- doing a Math.Floor on that result
- casting that result back to an int

If we just keep everything internally as an int, the division will
already round down and we can avoid all the random extra casting.
Makes it clear this is not a base type of the other ones.
@jasonmalinowski jasonmalinowski force-pushed the log-aggregator-cleanups branch from 0c1b6d8 to 69c194d Compare July 14, 2022 22:36
@jasonmalinowski jasonmalinowski marked this pull request as ready for review July 14, 2022 22:36
@jasonmalinowski jasonmalinowski requested a review from a team as a code owner July 14, 2022 22:36
@jasonmalinowski
Copy link
Member Author

@davidwengier Were you so excited to sign off on #61669 that you want to do it a second time? Here's your chance!

@davidwengier
Copy link
Member

@davidwengier Were you so excited to sign off on #61669 that you want to do it a second time? Here's your chance!

"Hey, that guy signed off on the PR that caused a bunch of perf regressions. We should get him to look at the new one too!"

Copy link
Member

@davidwengier davidwengier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks the same to me!

@jasonmalinowski jasonmalinowski merged commit 12c5b8f into dotnet:main Jul 15, 2022
@jasonmalinowski jasonmalinowski deleted the log-aggregator-cleanups branch July 15, 2022 20:42
@ghost ghost added this to the Next milestone Jul 15, 2022
@allisonchou allisonchou modified the milestones: Next, 17.4 P1 Jul 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants