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

Replace MarkKind::None with MarkKind::Output #18291

Closed
wants to merge 1 commit into from

Conversation

lhecker
Copy link
Member

@lhecker lhecker commented Dec 6, 2024

During the development of #18290 I noticed that we caused a performance
regression due to the storage of marks in attributes. Since the default
attribute is None and any output sets it to Output, this meant that
every row of output would at least temporarily allocate heap memory.
This caused cls on a huge history to take twice as long as before.

Validation Steps Performed

  • How do I test this? ❓

@lhecker lhecker added Area-Performance Performance-related issue Area-Output Related to output processing (inserting text into buffer, retrieving buffer text, etc.) labels Dec 6, 2024
@lhecker lhecker requested a review from zadjii-msft December 6, 2024 21:45
@@ -3316,8 +3315,6 @@ MarkExtents TextBuffer::_scrollMarkExtentForRow(const til::CoordType rowOffset,

endThisMark(lastMarkedText.x, lastMarkedText.y);
}
// Otherwise, we've changed from any state -> any state, and it doesn't really matter.
lastMarkKind = markKind;
Copy link
Member Author

@lhecker lhecker Dec 6, 2024

Choose a reason for hiding this comment

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

This lastMarkKind variable is only ever written to but never read.
The condition above, if (markKind != MarkKind::None), also seems wrong to me. Is it supposed to test lastMarkKind?

Copy link
Member

Choose a reason for hiding this comment

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

CC @zadjii-msft in case he has any thoughts here

Copy link
Member

@carlos-zamora carlos-zamora left a comment

Choose a reason for hiding this comment

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

Looks good to me. Just mildly concerned about this comment, but since we're changing the default value to "Output", this should probably work the same way as before.

@@ -3316,8 +3315,6 @@ MarkExtents TextBuffer::_scrollMarkExtentForRow(const til::CoordType rowOffset,

endThisMark(lastMarkedText.x, lastMarkedText.y);
}
// Otherwise, we've changed from any state -> any state, and it doesn't really matter.
lastMarkKind = markKind;
Copy link
Member

Choose a reason for hiding this comment

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

CC @zadjii-msft in case he has any thoughts here

Copy link
Member

@zadjii-msft zadjii-msft left a comment

Choose a reason for hiding this comment

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

okay I haven't read the code yet, but I did check out the branch, and this definitely broke selecting output.

@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Dec 11, 2024
@zadjii-msft
Copy link
Member

  • How do I test this? ❓

If you enable shell integrations, and then also enable the right-click context menu, that's usually the easiest way.

Though the ControlCoreTests::TestSelectOutput* tests should also cover this

@@ -3280,7 +3279,7 @@ MarkExtents TextBuffer::_scrollMarkExtentForRow(const til::CoordType rowOffset,
const auto nextX = gsl::narrow_cast<uint16_t>(x + length);
const auto markKind{ attr.GetMarkAttributes() };

if (markKind != MarkKind::None)
if (markKind != MarkKind::Output)
Copy link
Member

Choose a reason for hiding this comment

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

You know, entirely removing this conditional seems to work, form 1 minute of playing with it

@lhecker
Copy link
Member Author

lhecker commented Dec 11, 2024

I'll just bump the attributes vector size from 1 to 3. That seems easier to me until we have differential compression of attributes. That is, instead of storing run-lengths, store changes-between-lengths. Removing the charOffset vector from ROW will be much more effective for reducing the ROW size than caring about the attribute vector IMO.

@lhecker lhecker closed this Dec 11, 2024
@lhecker lhecker deleted the dev/lhecker/perf-marks branch December 11, 2024 20:26
@microsoft-github-policy-service microsoft-github-policy-service bot added Needs-Attention The core contributors need to come back around and look at this ASAP. and removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something labels Dec 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Output Related to output processing (inserting text into buffer, retrieving buffer text, etc.) Area-Performance Performance-related issue Needs-Attention The core contributors need to come back around and look at this ASAP.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants