Skip to content
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

Avoid allocations in LightupHelpers.CanWrap... methods #8107

Merged
merged 4 commits into from
Oct 18, 2023

Conversation

martin-strecker-sonarsource
Copy link
Contributor

Fixes #8106

@martin-strecker-sonarsource
Copy link
Contributor Author

The CanWrap... methods don't allocate anymore (only one shown here):

Before:
image

After:
image

@martin-strecker-sonarsource martin-strecker-sonarsource changed the title LightupHelpers CanWrapNode, CanWrapOperation and CanWrapOperation are performance sensitive LightupHelpers CanWrapNode, CanWrapObject and CanWrapOperation are performance sensitive Sep 28, 2023
Copy link
Contributor

@andrei-epure-sonarsource andrei-epure-sonarsource left a comment

Choose a reason for hiding this comment

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

// Avoid creating the delegate if the value already exists
bool canCast;
if (!wrappedObject.TryGetValue(obj.GetType(), out canCast))
if (!SupportedObjectWrappers.TryGetValue(underlyingType, out var wrappedObject))
Copy link
Contributor

Choose a reason for hiding this comment

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

is there a reason not to make these changes upstream, and afterwards copy them here?

The initial idea of the ShimLayer was that we only keep the code from them. Modifying it may require changes in licensing, keeping track of the changes and mentioning them.

Copy link
Contributor

Choose a reason for hiding this comment

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

actually the MIT license permits modification

still, I find it cleaner to make the change upstream first, improving your impact

It's true that this change will improve our analyzer first, we can merge it, but I'm afraid that if we don't keep track of what we modify, we'll get out of sync and in the future when doing updates we will forget that we did this and we'll just update the file from upstream , losing the change, because that's what we've done until now

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We are quite a lot out of sync with the two SourceGenrators already. I don't know about the other files, as it is unclear what we added and what was copied from StyleCop. This file is out of sync as well (we have 877 lines and StyleCop 678).
Waiting for the upstream repo to react is also an unfortunate burden. I can create a PR, but I would keep it separate from this one. Once the upstream PR is merged, we may copy the file content over, but it seems we added some functionality in this file in the past.

Copy link
Contributor

Choose a reason for hiding this comment

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

yes, we should not wait for upstream but we should always contribute back, and it doesn't seem we have this process in place

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@martin-strecker-sonarsource
Copy link
Contributor Author

The upstream pull request was approved with changes:
DotNetAnalyzers/StyleCopAnalyzers#3711 (review)

I synced this PR with the changes from there in c59a99b

@sonarcloud
Copy link

sonarcloud bot commented Oct 18, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
No Duplication information No Duplication information

@sonarcloud
Copy link

sonarcloud bot commented Oct 18, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
No Duplication information No Duplication information

@andrei-epure-sonarsource
Copy link
Contributor

I suggest making the PR title (which will be in the commit) like DotNetAnalyzers/StyleCopAnalyzers#3711 ?

@martin-strecker-sonarsource martin-strecker-sonarsource changed the title LightupHelpers CanWrapNode, CanWrapObject and CanWrapOperation are performance sensitive Avoid allocations in LightupHelpers.CanWrap... methods Oct 18, 2023
{
canCast = wrappedObject.GetOrAdd(
obj.GetType(),
kind => underlyingType.GetTypeInfo().IsAssignableFrom(obj.GetType().GetTypeInfo()));
Copy link
Contributor

Choose a reason for hiding this comment

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

this was very weird... the key kind was not used at all...

Copy link
Contributor

@andrei-epure-sonarsource andrei-epure-sonarsource left a comment

Choose a reason for hiding this comment

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

LGTM!

@andrei-epure-sonarsource andrei-epure-sonarsource merged commit e2bcd79 into master Oct 18, 2023
31 checks passed
@andrei-epure-sonarsource andrei-epure-sonarsource deleted the Martin/CanWrap_Allocations branch October 18, 2023 10:21
@andrei-epure-sonarsource
Copy link
Contributor

pls don't forget to merge upstream as well DotNetAnalyzers/StyleCopAnalyzers#3711 (review)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

LightupHelpers CanWrapNode, CanWrapObject and CanWrapOperation are performance sensitive
2 participants