On Tue Mar 19, 2024 at 6:42 PM CDT, ~corneliusroemer wrote:

I love the looks and features of ijq. Unfortunately it's too slow to be usable for a 16MB JSON file which I used to test drive the brew installed ijq on my M1 Pro (32GB).

What seems to be slow is the output parsing of a jq command. When the output is short, there's no delay, but when the output is on the order of MB, the screen freezes for multiple seconds.

This is the test file: https://github.com/ynqa/jnv/files/14657897/test.json

Thanks for the report and for providing the test file. I'm able to reproduce the problem and indeed it is unusably slow with that input.

I've been looking at this for a bit already and I think I've found some areas where we can improve performance.

Right now, every time the text input (filter) is changed we call tview's QueueUpdate function (in a goroutine) to execute jq against the new filter and write the output to the output view.

But the QueueUpdate function blocks the main application thread, so this is not the right approach (I think I've gotten away with this so far because it's usually pretty fast).

The better thing to do is to run the jq process in its own goroutine which writes to the output text view. We then use an "on changed" callback in the output text view to redraw the application.

Testing this locally makes a dramatic improvement (typing feedback is immediate, and updates to the output view are much faster). But before I commit it I need to test further to make sure I didn't regress anything else.

This also does not help with the startup time at all, which is still quite slow.

If you'd like to test the changes yourself, you can build off of the perf branch.

I've merged the perf branch into master. Using the test input you provided, the difference is substantial. I'm going to test the changes on master for a little bit before creating a new release, but this will be a huge improvement for all ijq users.

Thank you for the issue report!