According to the linked homepage, the memory usage seems decent (few hundred megs for most use cases when working with a 3.3G logfile). There's a screenshot with various tasks and what the peak memory usage is.

At some point you need to keep quite a large context in memory to have both decent performance and useful features (that aren't unbearably slow to use). lnav seems to land at a reasonable middle ground.

> At that time lnav basically just kept everything in memory.

lnav has never really kept the contents of files in memory. It does build an index of every line in a file. One exception is that it will decompress small gzip files and keep them in memory as a tradeoff from decompressing on the fly.

The memory consumption has never been a problem for me. So, it's not something I've ever focused on.

every editor ever :)

Yep, I would say the stiffest competition for lnav is the old tools[1]. I would just hope folks could have an open mind and give "new" things a chance (although lnav has been on github for 17 years).

[1] - https://lnav.org/2013/09/10/competing-with-tail.html