Listbox loading a million rows

Bodevinaat

Summary

I used this code to populate a listbox

For I As Integer = 0 To 1000000
  ListBox1.AddRow([I.ToString(), I + 1.ToString(), I + 2.ToString()])
Next

I was surprised that it took 63 minutes and 14 secs. So I tried following code as type conversions tend to be slow:

ListBox1.Visible = False
For I As Integer = 0 To 1000000
  ListBox1.AddRow(["A", "B", "C"])
Next
ListBox1.Visible = True

This code took 52 minutes and 3 secs. I noticed that both the listbox and the window remain responsive.

Objo Studio Version

26.6.2

Operating System

Windows 11, Intel Core I7, 32 Gb

Steps To Reproduce

Use the code

Expected Result

Should take a few secs like 10-30 max. Maybe you can implement some kind of OnBeforeUpdate event that freezes the listbox upon updating? As a reference, the second code in Xojo takes 1 minute 32 secs.

Garry

Thanks for the report. I reproduced the underlying performance issue with a smaller row count rather than trying to verify a full million-row load.

The important bit is that desktop Objo apps run user code on the VM thread, while Avalonia UI work has to happen on the UI thread. Previously, every ListBox.AddRow() synchronously hopped over to the UI thread, appended one row to the underlying Avalonia DataGrid’s bound collection, recalculated column widths, and invalidated painting. That meant a loop adding thousands of rows caused thousands of UI-thread updates.

I’ve changed the ListBox implementation so AddRow() updates the ListBox’s logical row store immediately, preserving RowCount, returned row indexes, CellTextAt(), etc. The Avalonia backing DataGrid-visible rows are now updated in batches. For large pending batches, the ListBox swaps the visible row source in one refresh rather than issuing one DataGrid collection notification per row.

In local testing here on my M4 Max MacBook Pro:

100,000 rows went from about 3.6 seconds to about 85 ms total for loop plus UI catch-up.
200,000 rows went from about 18 seconds to about 150 ms total.
Paint/layout invalidations dropped from one per row to essentially one bulk refresh.

This fix will be in the next release: https://feedback.objo.dev/bug/455

Bodevinaat

Hi Gerry,

You -should- check on a Windows machine. While the code runs on my M4 Mac under 5 secs for 100.000 rows, on a Windows machine it is ridiculously slow, >51 secs on a AMD Ryzen 3.

Garry

Thanks for the nudge to check this on Windows.

I’ve now added a temporary benchmark for the ListBox.AddRow() path and run it on both my M4 Max MacBook Pro and a Windows machine. The benchmark runs Avalonia headless, appends rows through the same Objo ListBox.AddRow() implementation, then verifies that the backing Avalonia DataGrid-visible row source catches up to the logical row count.

The important thing: I’m not seeing the huge slowdown on current main.

On my M4 Max MacBook Pro, after the batching change, 100,000 rows produced:

- native reused array: 34 ms
- lb.AddRow(["A", "B", "C"]): 130 ms
- hidden ListBox + constant array: 126 ms
- i.ToString() array: 75 ms

On Windows, using a Framework Laptop 16 with an AMD Ryzen AI 9 HX 370, Windows 10.0.26200, .NET 10.0.7, 100,000 rows produced:

native reused array: 63 ms
lb.AddRow(["A", "B", "C"]): 149 ms
hidden ListBox + constant array: 104 ms
i.ToString() array: 152 ms

I also ran the same benchmark with 1,000,000 rows on Windows to check for a large-loop, recursion, dispatcher backlog, or memory cliff:

native reused array: 647 ms total, 21 ms UI catch-up, 1 paint invalidation
lb.AddRow(["A", "B", "C"]): 1,035 ms total, 21 ms UI catch-up, 2 paint invalidations
hidden ListBox + constant array: 939 ms total, 20 ms UI catch-up, 2 paint invalidations
i.ToString() array: 1,324 ms total, 22 ms UI catch-up, 2 paint invalidations

Each run finished with the logical row count and displayed row count both exactly matching the requested row count.

So at the moment my working theory is that the batching fix I've made for the next release has probably addressed the main problem. Before that change, every AddRow() synchronously updated the underlying Avalonia DataGrid row collection and triggered UI/layout work per row. Current main updates Objo’s logical row store immediately, but batches the Avalonia-visible row refresh, and for large batches swaps the visible row source in bulk.

That said, this benchmark is still not a full end-user app with a visible window being painted continuously, so there may still be another Windows-specific path to investigate if you can reproduce the slowdown in the next build containing this fix. The original report was against Objo Studio 26.6.2, which does not include this change. Once the next build is available, I’d be very interested to know whether the same million-row test is still slow on your Windows machine.

Bodevinaat

Garry Very well. This a strange case. I have an AMD Ryzen 3, and two Intel Core I7's, one with 16 Gb and one with 32. On all 3 machines the code runs this slow with some slight variations, while my MacBook M4 is as fast as yours.

Thanks for investigating this.

Bodevinaat

Bodevinaat Hi Garry, tested with 26.6.4. Indeed lots of improvement. 100,000 rows takes about a 900-1100 ms.
Very good. A million rows takes 6600 ms. Faster than one might expect. One caveat though: the responsiveness of the listbox is gone now.

Garry

Have you tried the new release? V26.6.4 dropped last night?

rgb

Garry

HI @Garry, new version missing in blog & announcements 🙂

Garry

Oops, my bad:

https://forum.objo.dev/d/393-objo-studio-v2664-released

rgb

Garry

Missing in If Not Nil

Garry

Thanks - fixed: https://ifnotnil.com/t/objo-studio-v26-6-4-released/4714