-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Optimize parsing/conversion of TextDecorations from string, reduce allocations #9778
base: main
Are you sure you want to change the base?
Conversation
i++ | ||
); | ||
// Flags indicating which pre-defined TextDecoration have been matched | ||
byte matchedDecorations = 0; |
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 think it would be cleaner with 4 separate bool variables instead of a single byte variable. IMO it's overly complicated for no benefit. The original code was using the index in the array as the bit but since you changed it to separate ifs instead of the array, you can now use separate booleans.
// Error: Separator is at the end of the input | ||
nextNameStart = -1; | ||
} | ||
if (decoration.Equals("Overline", StringComparison.OrdinalIgnoreCase) && (matchedDecorations & OverlineMatch) == 0) |
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 think you should flip this condition, do the cheaper check first:
if (decoration.Equals("Overline", StringComparison.OrdinalIgnoreCase) && (matchedDecorations & OverlineMatch) == 0) | |
if ((matchedDecorations & OverlineMatch) == 0 && decoration.Equals("Overline", StringComparison.OrdinalIgnoreCase)) |
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.
Since this would be a case when we're already going to throw if it doesn't work out, the other day @miloush told me I don't need to optimize anymore; comparing the text first seemed more readable as you get it aligned under eachother.
(miloush, what is that thumbs up doing there?!)
public override object ConvertTo(ITypeDescriptorContext context, CultureInfo culture, object value, Type destinationType) | ||
{ | ||
if (destinationType == typeof(InstanceDescriptor) && value is IEnumerable<TextDecoration>) | ||
// Go through each item in the input and match accordingly |
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.
This is my personal opinion, feel free to take it or leave it:
I've noticed in your PRs that you tend to add a lot of comments to explain what your code does, essentially duplicating the logic in the code and in the comment. These types of comment tend to make it harder to read the code, modify the code and they often become outdated when the code changes. Comments are most useful when explaining why the code does what it does, adding a reference to something (Like an issue or web link) or explaining something that is not easily understandable by reading the code.
If you want to read more about this, I would suggest this blog post which goes into more details: https://stackoverflow.blog/2021/12/23/best-practices-for-writing-code-comments/
Your PR doesn't seem to go against any of the coding guidelines so at the end of the day it's up to the WPF team to decide if you need to change anything in your PR.
Again, this is my personal opinion and I won't pretend I'm the absolute authority when it comes to code comments. This is merely a suggestion since I don't know your background and I don't know if you might find this suggestion useful.
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.
Thanks Thomas, I agree this one for example isn't that relevant and just duplicates the whole proc.
Working with large codebases especially written in C and some still in assembly, same as largely working with disassembly (not everyone gets the beauty of working with VS, the debugger its tooling), you start to comment way more even the more obvious things to follow the train of thought.
Often times, when fixing bugs, debugging, few years after someone, you'll find that the most important thing is not the code written, but the intention behind one programmer's code (which often is just a comment, since they left). People make mistakes, today's CRs and collaboration over one's code are way more prevalent than they used to be (at least in my experience), and when you don't have that clue, it is harder to debug and fix such code should there be a bug. Does maintability in case of any refactoring hurt? Yes, you have to take care of the comment. Does it help you to make more informed decision? It does.
Then again, we're in .NET when most things are way more expressive and it is easier to go through code itself and understand the intent because multiple things are abstracted away, so less comments like this are needed. When I do these refactorings on whole class, I just write down comments on stuff I shouldn't forget and then just run with it, and yes, sometimes I do not delete them ("add" them instead).
So it is indeed something I could improve on when swapping to .NET each time. Habits die hard.
Description
Optimize parsing of
TextDecorations
from string intoTextDecorationCollection
, reduces allocations in all steps and improves performance, also reduces the memory footprint + readibility of the entire class by a large amount.TextDecorationNames
, that also removes the strings allocations on its own (not used anywhere else).PredefinedTextDecorations
, which was redundant from the start.ConvertFromString benchmarks
Customer Impact
Improved performance, decreased allocations.
Regression
No.
Testing
Local build, CI, extensive assert testing:
Risk
Should be safe, I believe I've tested thoroughly all cases and we shall have no surprises.
Microsoft Reviewers: Open in CodeFlow