Table widget slow in cocoa

[areslagae]

Describe the bug

Hi all,

I am porting a tkinter application to Toga so I can make use of Briefcase. So far I like Toga a lot (my code seems simpler and shorter than the tkinter code). I am experiencing issues with the performance of the Table widget in macos / cocoa however.

Please refer to the minimal code sample below. When pressing the button, 10 rows are added to a 20 col table. This operation takes one full second (button click ... rows appearing). With more rows, when scrolling the table, if frequently seems to "hang" for a short time. There are many situations where the one second update would not be an issue, but for the application in question (which modifies the table data frequently) it is. A workaround or fix allowing fast table updates would be great.

Otherwise my experience with the Table widget so far is quite good. What would be welcome however, next to fast data updates, is a way to set the height of the table in rows rather than pixels, and maybe a way to specify relative column widths. Also every cell in the table seems to always be editable, which I assume will be confusing to users if that is not intended by the application.

I might be missing something - first day with Toga - feel free to point out.

Steps to reproduce

import toga
from toga.style import Pack
from toga.style.pack import COLUMN
import random

class App(toga.App):
    def startup(self):
        self.main_window = toga.MainWindow(title=self.name)
        headings = [f'col{i}' for i in range(20)]
        self.table = toga.Table(headings=headings, data=None, style=Pack(flex=1))
        button = toga.Button('Add Rows', on_press=self.add_rows, style=Pack(padding=10))
        self.main_window.content = toga.Box(children=[self.table, button], style=Pack(direction=COLUMN))
        self.main_window.show()
    
    def add_rows(self, widget):
        for _ in range(10):
            row = {f'col{i}': ''.join(random.choices('Toga', k=4)) for i in range(20)}
            self.table.data.append(row)
        self.table.refresh()

def main():
    return App('Minimal Slow Table Example', 'org.beeware.examples.minimal-slow-table-example')

if __name__ == '__main__':
    app = main()
    app.main_loop()

Expected behavior

An almost immediate update, like in other gui toolkits.

Screenshots

No response

Environment

• Operating System: macos 10.15.7
• Python version: 3.9
• Software versions:
  • Briefcase:
  • Toga: 0.4.5
  • ...

Logs

Additional context

No response

[freakboy3742]

(Converted into a discussion because it's still in the investigation stage, rather than a specific bug that can be resolved).

Firstly - one really small optimisation - you shouldn't ever need to call refresh(). Although the API endpoint exists, it should be considered an internal detail - it's used to trigger re-evaluations of the box layout, and should be invoked automatically when required. It definitely won't be doing anything productive in this case. That said, it also won't be a major source of slowdown... but it's worth noting regardless.

I'm not able to reproduce a delay that is as bad as you're reporting. The fact that you're on macOS 10.15 and Python 3.9 suggests you've got an older x86-64 MacBook; if that's the case, that will be at least some of the cause of the delay you're seeing. You might see an improvement if you upgrade to Python 3.12 - recent Python versions have seen signficant speed boosts.

However, I don't think that update alone will address the issue you're seeing. While I don't see a "1 second" delay, I do see a delay, for which I can think of two contributing causes.

The first is that creating a visible row requires creating a number of Objective C objects, and that process takes time. I don't know if this matches your experience, but in my testing, once the visible table has been filled, adding rows that aren't visible seems a little faster. This is because the underlying macOS Table implementation is optimised so that it won't try to render rows that aren't visible - so they're created on demand when they become visible.

Unfortunately, the fix for this is "make the Rubicon bridge faster" - and that isn't a trivial fix. Object creation is known to be slow because it involves some complex interactions between Python and Objective C; while there's possibly some ways that it could be sped up, those approaches require some fairly deep changes to Rubicon.

The second cause is the nature of "bulk" updates like this. Adding 10 individual rows one at a time is not the same as adding 10 rows in one chunk; after adding each row, there are details about the entire table that need to be recomputed. When you insert 10 rows in rapid succession, there's a lot of duplicated (and ignored) effort.

Toga doesn't currently have any "bulk update" APIs for list sources (e.g., data.extend() rather than N calls to data.append()). Adding an extend() API itself wouldn't be that difficult; but modifying the backends to perform optimised redraws based on that information would be a little more complicated. I've opened #2747 to track this as a potential enhancement.

So - what can you do in the meantime?

Depending on your specific use case, you may find that it is faster to replace all the data, rather than add individual rows one at a time. Refreshing the entire table uses a different mechanism to inserting a row; depending on your specific use case, you might find that refreshing all the data is marginally faster:

    def add_rows(self, widget):
        for _ in range(10):
            row = {f"col{i}": "".join(random.choices("Toga", k=4)) for i in range(20)}
            self._data.append(row)

        self.table.data = self._data

Whether this helps will be very dependent on your specific use case.

The other possibility is to provide better visual feedback of progress. As currently implemented, your add_rows() method blocks the GUI event loop until it has completed adding all the rows. In your case, there's a 1 second delay as 10 rows are added; this is because the method blocks the GUI event loop until it has finished. However, with a small change, you can get the GUI to refresh in between updates:

    async def add_rows(self, widget):
        for _ in range(10):
            row = {f"col{i}": "".join(random.choices("Toga", k=4)) for i in range(20)}
            self.table.data.append(row)
            await asyncio.sleep(0)

By making the method asynchronous, and awaiting a 0 second sleep, you give the button handler permission to hand control back to the GUI event loop, allowing the GUI to redraw. You should see rows being added at the speed they are created, rather than pausing until all the rows are ready. It's not a perfect solution, but it will at least providing visual feedback as fast as it can be provided, which might be enough for UX purposes.

[areslagae]

freakboy3742,

Many thanks for your feedback.

I did some further testing:

• about eliminating refresh(): This indeed does not make a significant difference.
• about python 3.9 vs. 3.12: Running any Toga program with python 3.12 results in a “Segmentation fault: 11” on my laptop. This is why I moved to an earlier python version. I have not investigated further.
• about replacing all the data at once: This does not seem to make a difference.
• about blocking the main loop and adding rows async: The button handler that add the rows finishes almost immediately. After that, it takes roughly an additional second of time for visually updating the table. The source of slowness seems to be in another thread?

As a work-around I have for the time being implemented pagination. I now only show one "page" of data in the table (~ 10 - 16 items) combined with page control (first/previous/next/last page buttons) below the table.

[freakboy3742]

Thanks for that update. Regarding the last bullet point - the Toga handler may well return quickly; however, if you're doing a large update of individual rows, it might be queuing a lot of work for Cocoa to process. Cocoa will attempt to optimise the number of drawing operations it performs, and that is what manifests as a 1 second delay before the visual update.

The purpose of making the callback asynchronous with an await is to break the "one big visual update" into a series of smaller ones, giving Cocoa the opportunity to clear the backlog before doing more work.

If you're able to narrow down the segmentation fault into a reproducible example, that's definitely of interest, because Toga apps shouldn't crash.