News for hackers. Stuff that matters.
Re:SQLite-TUI: A TUI for viewing SQLite databases, written i... by Aeolun on Saturday September 04, 2021 @07:10AM (#28414014)
I just honestly cannot imagine how it could start to be slow at a few thousand rows. Calling it an optimization feels wrong somehow.

Glad you hear you are planning to look at it though :)

Re:SQLite-TUI: A TUI for viewing SQLite databases, written i... by laumars on Saturday September 04, 2021 @08:12AM (#28414374)
Larger querying larger databases should be a problem for the RDBMS not for the UI wrapper. So I’d wager he is processing every record on the db irrespective of whether it’s visible on screen or not. It would explain the TUI panic posted elsewhere too.
Re:SQLite-TUI: A TUI for viewing SQLite databases, written i... by mathaou on Saturday September 04, 2021 @08:52AM (#28414630)
I have no control over which portions of the screen get updated when without updating the library I'm using.
Re:SQLite-TUI: A TUI for viewing SQLite databases, written i... by laumars on Sunday September 05, 2021 @05:13PM (#28427856)
One way to optimise this is to pull back the entire SQL results in an [][]interface{} (row, column) but then only pass a sub-slice to your TUI (depending on how many rows are visible).

I assume your term library doesn’t create the actual table? So you’d know the term height and you’re then plotting the cells? If that’s not the case then I don’t think you’ll get much further with this project without switching to another term library (or rolling your own — which is actually easier than it sounds).

Re:SQLite-TUI: A TUI for viewing SQLite databases, written i... by mathaou on Sunday September 05, 2021 @05:33PM (#28428025)
Lol I just did this. Now way faster and can handle arbitrary amounts of data (there is some flickering on scroll for large data sets I'm trying to sort out).