Intermediate heap allocations

[TheTonttu]

I was wondering has anyone taken a closer look at Terminal.Gui intermediate heap allocations?

OS: Windows 10 22H2 (build 19045.3086)

VS2022 performance profiler ".NET Object Allocation Tracking" shows quite a lot of intermediate System.Rune[] allocations from Terminal.Gui.TextFormatter calls on redraw. This is mostly seen when something is updated in time intervals, e.g. progress bar or a time display.

The UI Catalog Progress demo is one example of this. Although bear in mind it seems to also have lot of func and enumerator allocations which is probably just related to how the main loop invocations and progress bar are used in that demo.

On another note, I ran the same Progress demo on v2_develop branch in hopes of seeing improvement. Sadly the heap allocations have increased drastically. This time coming from Terminal.Gui.LineCanvas which might just be due to some temporary regression.

[tznind]

Is this a performance bottleneck? Can you give an example of part of the code that is slow because of this and how it might be changed to be faster?

[TheTonttu]

Thanks for the reply,

I haven't had a chance to take a closer look at the code yet so I cannot pinpoint anything specific. I was mainly curious if the project has had a look at the performance and allocations now that v2 is being developed and it is dropping support for older .NET versions.

It is probably not a performance bottleneck in itself but when using multiple libraries that have similar allocation characteristics then the cumulative effect can become bottleneck at the application-level, especially if doing near real-time stuff. Although you could argue maybe GC languages aren't the best choice then but that's besides the point. I would still prefer library code strive for maximum performance wherever possible if it does not make the internals or public interfaces convoluted.

.NET 5+ introduced a lot of simple APIs surrounding spans that could be used with encoding, runes and intermediate string manipulations. There are probably also some places in general that could utilize array pooling via ArrayPool and object pooling via Microsoft.Extensions.ObjectPool or with simple shared objects.

I could take a closer look in case there are any low-hanging fruit gains to be had if that's ok? Would probably need to add a benchmark project to the solution to verify any modification does not just make the performance worse.

[tznind]

I could take a closer look in case there are any low-hanging fruit gains to be had if that's ok?

Performance is always nice to have! And it sounds like you have some expertise in this area. Definitely all PRs are welcome.

From a purely performance perspective, the two areas I have found issues with are:

• Repeated refreshes e.g. when resizing the console screen on windows
• TextView with large files

I think that resizing is more about the number of times the events are raised in succession than the performance of each iteration itself.

I think the performance bottleneck is often the console itself and/or communication with the console (moving cursor location, clearing screen etc). But I would be happy to find out I am wrong :)

There is some v2 restructuring on TextView already but it is mostly around better support for dynamic coloring #2682 (e.g. parsing text and performing syntax highlighting). So it might not be the best place to focus changes.

If you have identified LineCanvas as a potential area for improvement then could be a good place to start. It would also give a fairly self contained bit of code to test out your proposed changes.

I originally wrote LineCanvas so can also advise on design questions you have.

LineCanvas is responsible for resolving N horizontal/vertical lines of varying styles into a single 'bitmap' of Rune that can be rendered onto the screen. The goal being to create a seamless frame where double lines join to single lines, corners are all correct etc. See the LineDrawing scenario in UICatalog to understand how it works.

[TheTonttu]

Thanks for the details. I agree that improving the parts directly involved with console would most likely have the biggest impact on performance.

Unfortunately I'm not that comfortable touching any of the major console or view components yet, My first wave of changes, if any, would revolve around the smaller utility classes/methods so most likely you won't see any major performance increase. But I would also be happy to be wrong about that. 😄

If I get the utilities sorted then I might take a look at LineCanvas.

Do you want to close this issue or keep it open as reference for any potential future PRs?

[tznind]

If I get the utilities sorted then I might take a look at LineCanvas.

Do you want to close this issue or keep it open as reference for any potential future PRs?

Cool, lets leave this issue open for now - at least until the first PR is merged. Make sure you branch off v2_develop not develop.

[Decimation]

I was wondering this as well.

VS2022 performance profiler ".NET Object Allocation Tracking" shows quite a lot of intermediate System.Rune[] allocations from Terminal.Gui.TextFormatter calls on redraw. This is mostly seen when something is updated in time intervals, e.g. progress bar or a time display.

I'm getting similar warnings from the profiler for Color and Attribute. This seems to be caused by the Redraw function for TableView.

[dodexahedron]

Just a thought, here, and sorry if it isn't relevant, but:

In v1, is it possible a significant portion of that is due to the usage of the NStack.ustring type for text?

[BDisp]

No, it doesn't. You are using MdiContainer and I didn't test with it but I haven't access to a computer for the next 3 hours. As soon as possible I will check it. Thanks for your help.

[BDisp]

No, it doesn't. You are using MdiContainer and I didn't test with it but I haven't access to a computer for the next 3 hours. As soon as possible I will check it. Thanks for your help.

Sorry wrong topic. This is what happens by answering through the mobile phone still sleeping :-)