4 ms·
Optimizations like that will be part of the next alpha release after the one I'm working on.
by mathaou 5y ago
Optimizations like that will be part of the next alpha release after the one I'm working on.
- Aeolun 5y agoI 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 :)
- laumars 5y agoLarger 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.
- mathaou 5y agoI have no control over which portions of the screen get updated when without updating the library I'm using.
- laumars 5y agoOne 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).
- mathaou 5y agoLol 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).