restrict the number of render()

[nschloe]

I'm trying to bring down the CPU usage of tiptop by rendering less often. The data itself is updated every 2 seconds, and I'm enviously looking at rich.live's auto_refresh=False. Is there something like that for Textual as well?

Perhaps Textual isn't even the right lib for me and I should go for rich.live (although that brings other difficulties).

[willmcgugan]

You could set an interval on the app which calls self.refresh. And don't set the interval within your widgets. So you can make it refresh the entire interface very 2 seconds.

BTW I did some profiling on tiptop. In a 61 second execution time, tiptop spends 2.857s rendering the interface.

tiptop profile.html.zip

[nschloe]

You could set an interval on the app which calls self.refresh.

How do I do this?

from textual.app import App
from textual.widget import Widget

from rich.panel import Panel
from rich import box


class RenderCounter(Widget):
    def on_mount(self):
        self.k = [0]
        # self.set_interval(2.0, self.refresh)

    def render(self) -> Panel:
        self.k.append(self.k[-1] + 1)
        return Panel(
            " ".join([str(item) for item in self.k]),
            box=box.SQUARE,
        )


class CounterApp(App):
    async def on_mount(self) -> None:
        await self.view.dock(RenderCounter(), size=10)
        self.set_interval(2.0, self.refresh)


CounterApp.run()

This little render()-counter doesn't update.

BTW I did some profiling on tiptop.

Interesting! Never used pyinstrument, thanks for pointing it out.

2.857s in 61s amounts to about 4.7% constant CPU usage; let's see if I manage to cut it down. I see now that other calls also take some time, let's see if I can cut down on those as well.

[willmcgugan]

This little render()-counter doesn't update.

Ah, I think that's because there is a cache of the previous render that won't be cleared until you call Widget.reresh().

Come to think of it, refreshing the screen in one go isn't going to buy you much.

I think there are some other worthwhile optimisations you should try first. Try not to use console markup in your table cells, which requires a separate parse step. Use a rich.text.Text class instead. i.e. replace "[red]" + data + "[/red]" with Text(data, style="red")

Ultimately though, it's tables which are expensive. They are very flexible with a lot of options, but a dedicated data table that just rendered text and numbers could be a lot faster.

We're also planning on doing a lot of optimizing work on Rich, so things might just get faster soon without any effort. :)

[nschloe]

I think there are some other worthwhile optimisations you should try first.

I replaced most of the explicit []-statements by style=, but it didn't do too much. pyinstrument indicates that most of the time is spend updating the view. (Only the lower part is tiptop-code.)

└─ 5.918 _run  asyncio/events.py:78
 └─ 5.769 process_messages  textual/message_pump.py:177
    └─ 5.767 _process_messages  textual/message_pump.py:186
       └─ 5.716 dispatch_message  textual/message_pump.py:227
	  ├─ 3.524 on_message  textual/message_pump.py:263
	  │  └─ 3.513 invoke  textual/_callback.py:15
	  │     └─ 3.512 handle_update  textual/view.py:102
	  │        └─ 3.335 update_widget  textual/layout.py:375
	  │           └─ 3.324 render  textual/layout.py:296
	  │              └─ 2.963 _get_renders  textual/layout.py:250
	  │                 └─ 2.953 _get_lines  textual/widget.py:199
	  │                    └─ 2.952 render_lines  textual/widget.py:186
	  │                       └─ 2.906 render_lines  rich/console.py:1260
	  │                          └─ 2.905 split_and_crop_lines  rich/segment.py:254
	  │                             └─ 2.769 render  rich/console.py:1210
	  │                                └─ 2.639 __rich_console__  rich/panel.py:135
	  │                                   └─ 2.489 render_lines  rich/console.py:1260
	  │                                      └─ 2.488 split_and_crop_lines  rich/segment.py:254
	  │                                         └─ 2.382 render  rich/console.py:1210
	  │                                            └─ 2.354 __rich_console__  rich/padding.py:79
	  │                                               └─ 2.338 render_lines  rich/console.py:1260
	  │                                                  └─ 2.335 split_and_crop_lines  rich/segment.py:254
	  │                                                     └─ 2.231 render  rich/console.py:1210
	  │                                                        ├─ 1.356 __rich_console__  rich/table.py:437
	  │                                                        │  └─ 1.020 _render  rich/table.py:709
	  │                                                        │     └─ 0.819 render_lines  rich/console.py:1260
	  │                                                        │        └─ 0.808 split_and_crop_lines  rich/segment.py:254
	  │                                                        └─ 0.854 render  rich/console.py:1210
	  │                                                           └─ 0.779 __rich_console__  rich/table.py:437
	  │                                                              └─ 0.650 _render  rich/table.py:709
	  └─ 2.180 on_event  textual/message_pump.py:249
	     └─ 2.173 invoke  textual/_callback.py:15
		└─ 1.920 on_timer  textual/message_pump.py:320
		   └─ 1.918 invoke  textual/_callback.py:15
		      ├─ 0.989 collect_data  tiptop/_procs_list.py:54
		      │  └─ 0.982 get_process_list  tiptop/_procs_list.py:11
		      │     └─ 0.977 process_iter  psutil/__init__.py:1398
		      │        └─ 0.774 as_dict  psutil/__init__.py:500
		      └─ 0.755 collect_data  tiptop/_cpu.py:20

I should perhaps try to cut down on tables. Not sure what else to do.

[mharig]

I think you have to use the solution I proposed here.
And btw, tiptop needs near 7% CPU time on my laptop.