Initialize rows lazily #15524
Initialize rows lazily #15524
Conversation
lhecker
added
Product-Conhost
lhecker
force-pushed
the
dev/lhecker/buffer-lazy-commit
branch
2 times, most recently
from
c7b8783
to
11c2215
Compare
lhecker
force-pushed
the
dev/lhecker/buffer-lazy-commit
branch
2 times, most recently
from
d74e8fb
to
f2934ad
Compare
| @@ -495,7 +630,7 @@ void TextBuffer::_SetWrapOnCurrentRow() noexcept | |||
| // - fSet - True if this row has a wrap. False otherwise. | |||
| //Return Value: | |||
| // - <none> | |||
| void TextBuffer::_AdjustWrapOnCurrentRow(const bool fSet) noexcept | |||
| void TextBuffer::_AdjustWrapOnCurrentRow(const bool fSet) | |||
There was a problem hiding this comment.
gut feeling: the current row should not need to be faulted in, and so should not be exposed to a commit exception. Is that a faulty understanding on my part?
There was a problem hiding this comment.
It is possible for the current row to fault if you use CUP (or whatever) to go somewhere that hasn't been previously accessed or rendered yet (which is also possible since the renderer is async). We should decide whether we want to crash under OOM. It'd be a valid strategy. Alternatively we can strategically make use of a hypothetical GetRowByOffsetNoInit function that returns nullptr when faulting. I would personally not prefer it because it makes the code more complex (= "is it safe to use NoInit here? etc.), but I'm absolutely open to implement either change.
There was a problem hiding this comment.
Wow, love how much simpler some of this is!
Honestly, once you gave me an explanation of _commitWatermark, everything kinda just made sense. I suggest adding a big blurb at the top of textBuffer.hpp or near the _commitWatermark declaration. That'll help a ton.
I'm gonna approve, but I really do think the _commitWatermark comment will help. Nice work!
| step = -1; | ||
| } | ||
|
|
||
| for (; y != end; y += step) |
There was a problem hiding this comment.
I don't completely understand why this doesn't have the same problem as memcpy. Depending on the direction you are moving, we need to copy end-to-start or start-to-end, right?
There was a problem hiding this comment.
oh, i see. we are. this is just a generic loop that goes both ways. Oi.
There was a problem hiding this comment.
If you prefer we can make it 2 separate loops! I initially had 2 loops, and wrote this single loop because I was curious if I could.
There was a problem hiding this comment.
Deeply horrified that we are placement-new-ing and placement-delete-ing ROWs inline in the buffer, but honestly at this point I would expect nothing less than that.
I've read the code over a couple times and I think I trust it. It scares me, but I trust it. Let's go!
|
|
||
| // Retrieves a row from the buffer by its offset from the first row of the text buffer | ||
| // (what corresponds to the top row of the screen buffer). | ||
| ROW& TextBuffer::GetRowByOffset(const til::CoordType index) |
There was a problem hiding this comment.
for height=10, GetRowByOffset(1) and GetRowByOffset(11) are the same... but there are measurably not 11 rows in the buffer.
This isn't something to worry about, right?
There was a problem hiding this comment.
Yeah I think that's actually good, because it makes writing code that loops around simpler and safer. For instance, when you accidentally scroll (= rotate) more rows than there are in the buffer. The result will be weird, but it'll not crash and behave consistently.
Edit: Also, just double checking, it used to work the same way before this PR right?
There was a problem hiding this comment.
Actually, it's even preferable if you scroll less rows than there are in the buffer. For instance, let's say you want to copy the viewport contents of height 4 starting row 8. In your example it'll just copy row 8,9,10,11 = 8,9,0,1 and it'll not require the caller to perform any modulo or similar logic. It should just work. That's why I added the underflow / negative modulo if condition as well. It makes copying/scrolling rows backwards work correctly without extra logic.
lhecker
added
the
AutoMerge
microsoft-github-policy-service
bot
deleted the
dev/lhecker/buffer-lazy-commit
branch
| auto& row = _getRowByOffsetDirect(0); | ||
| row.Reset(_currentAttributes); | ||
| return row; | ||
| return _getRowByOffsetDirect(0); |
There was a problem hiding this comment.
wait, this wasn't explained in the new commit. why did it change? is this meaningful? the comment above the function is incorrect now.
There was a problem hiding this comment.
Ah sorry, I forgot to update the comment. I made the change because I wasn't sure what I'd need. Over the weekend I figured that out though, so in the PR I just opened I've fixed this. #15541
For a 120x9001 terminal, a01500f reduced the private working set of
conhost by roughly 0.7MB, presumably due to tighter
ROWpacking, butalso increased it by 2.1MB due to the addition of the
_charOffsetsarray on each
ROWinstance. An option to fix this would be to onlyallocate a
_charOffsetsif the first wide or complex Unicode glyphis encountered. But on one hand this would be quite western-centric
and unfairly hurt most languages that exist and on another we can get
rid of the
_charOffsetsarray entirely in the future by injectingZWNJs if a write begins with a combining glyph and just recount each
row from the start. That's still faster than fragmented memory.
This commit goes a different way and instead reduces the working
set of conhost after it launches from 7MB down to just 2MB,
by only committing ROWs when they're first used.
Finally, it adds a "scratchpad" row which can be used to build
more complex contents, for instance to horizontally scroll them.
Validation Steps Performed
^[[3Jerases scrollback ✅ScrollRowswith a positive delta ✅Reset. ❔ Unit tests use it though