Lnav unreasonably slow for long CSV string log.

[alabamagan]

lnav version
v0.12.2

Describe the bug
lnav becomes laggy when moving through long low strings. By "Long", I just mean csv with ~ 1000 elements > 50 lines. If the message spans across one page, lnav because unusable and will crash. Also, error traceback on python written by rich's log handler also tends to cause this problem. Sometimes it just crashes.

I think it's quite likely that logline field discovery is causing this issue, or perhaps the color codes written by rich have something to do with it.

To Reproduce
Steps to reproduce the behavior:
Try this log file:
rAIdiologist_2024-10-25.log

[tstack]

Took a quick look and it seems related to lots of ANSI escape sequences in a single log message. I'll look into trying to optimize it. Thanks for the report!

[alabamagan]

Hey I've been digging into the issue as it's getting disruptive. I think the database parser could have been the curpit. It's trying to find fields and values and when the string at one time point is very very long, it takes a very long time to try to parse it.

Is there a way I can turn of field value discovery?

[tstack]

I think this is fixed now on the top-of-tree. Movement is smooth and isn't using CPU when idling and the focus is on the exception dump in the rAIdiologist_2024-10-25.log file.

[alabamagan]

I think this is fixed now on the top-of-tree. Movement is smooth and isn't using CPU when idling and the focus is on the exception dump in the rAIdiologist_2024-10-25.log file.

Thanks for looking into this, have pulled and compiled to have a go with it. It's indeed way smoother. I think this issue can be closed