Comments 9
Для больших файлов я обычно использую notepad++ (под винду), работает достаточно шустро.
В похожей ситуации набросал tkinter GUI для питоновского polars. Строки не индексирую, но бонусом получил lazy loading и SQL для запросов к логам. До 30 секунд на практически любой запрос. Запускается и под виндой (python portable) и под линуксами.
В mcview всё, что написано в "Итог", есть, но открытие происходит быстрее, потому что "\n" индексировать не требуется.
vim/nvim для больших файлов. Плюс, сразу на сервере можно глянуть не качая
Говорят, Zed неплохо справляется.
Но как я понял, тут нужда именно в реализации на основе VSC. Отличное решение.
Пошел посмотреть на github как устроено кросскомпиляция, а ссылка видет на gitlab :(
1) Можно не хранить все смещения начала строк, а хранить только каждую сотую строку, например. Тогда можно сэкономить прилично памяти. А при переходе уже искать нужную строку. Тут правда есть опасность, что длина строки может быть, например, 100 Кб. Тогда можно считать смещение не только по номеру строки, а ещё и по объёму.
2) Можно сократить время индексации, если выполнять её в фоне = открыли файл, показали начало и запустили процесс индексирования. Можно вообще не индексировать файл до тех пор, пока первая опеарция случайного доступа не будет выполняться.
3) Ну и, наверное, можно с хранением смещений что-то придумать. А то u64 для номера строки как-то жирновато, если, например, в файле всего 100 000 строк.
Использую klogg - десятки гб на стром ноуте в легкую переваривает, включая поиск.
Zed?
Все пишут комментарии с вопросами/сомнениями по реализации.
А я напишу простое человеческое "Спасибо", выручил! Не всегда есть возможность открыть что-то удобное для логов, особенно когда это на удаленном узле.
Rust, mmap и 10 миллионов пикселей: делаем производительный Log Viewer для VS Code