Логов становится все больше и больше, а времени на их анализ и поиск всё меньше. Мне стало интересно, а есть ли разница в скорости и производительности популярных программ при работе с большими объемами текста. Оказывается есть! Будем сравнивать Notepad, Notepad++, TextPad и Atom в скорости поиска текста в лог-файлах.
Что будем измерять:
Время запуска.
Потребление памяти при старте.
Скорость открытия редактора и файла (100 Мбайт и 1 Гбайт).
Количество используемой оперативной памяти.
Поиск строки текста.
Поиск регулярного выражения.
Подробнее по железу, версиям софта и методам тестирования
текстовые редакторы:
- TextPad 8.12.0 (2022-05-14) (64-bit)
Тест проводился на ноутбуке Dell Latitude 5511 (i7-10850H, 32 Гбайт RAM, Windows 10) Время замерялось секундомером на телефоне. Измерения проводились на лог-файлах SIP-сервера. Для создания файла размером 1 Гбайт оригинальный файл размером 100 Мбайт был скопирован 10 раз. Для поиска использовалась строка "340170317_134134587" и регулярное выражение "340170317\_\d{8}7" либо '340170317\_[[:digit:]]{8}7'.
Желаемый результат поиска - вывод всех совпадений, найденных при запросе (функция "Find All in Current Document" в Notepad++)
Искомое значение встречалось 33 раза файле в 100 Мбайт и 330 раз в файле размером 1 Гбайт.
Время старта и потребление памяти
Начнем тест с сравнения времени старта и потребления памяти пустого окна редактора.
Таблица 1 – Время запуска и потребление памяти
App |
Start time |
RAM |
Notepad++ |
1 |
10 |
TextPad |
1 |
8 |
Atom |
2 |
367 |
Notepad |
1 |
4 |
Примечение
Start time - время в секундах для открытия редактора
RAM - количество Мбайт оперативной памяти, отображаемое в Диспетчере Задач
Время старта у большинства редакторов - секунда или даже меньше. Только Atom требует заметно больше, хотя и всего две секунды. Что касается потребления памяти, Atom уже на старте заметно вырывается вперед.
Тестируем файл размером 100 Мбайт
Изначально я пытался использовать меню “Открыть с помощью” из проводника, так как чаще всего логи открываю именно так. Однако, для Atom всегда появляется дополнительное инфо-окошко, которое нужно было вручную закрывать. Так что скорость открытия файла для Atom указана приблизительно. Кроме того, ради спортивного интереса, я решил грепнуть (grep) эти файлы в WSL (Ubuntu) в командной строке.
Таблица 2 – поиск по файлу размером 100 Мбайт
App |
Start time |
RAM |
Count |
Simple |
Regex |
Notepad++ |
1 |
220 |
1 |
1 |
1 |
TextPad |
1 |
43 |
1 |
1 |
1 |
Atom |
4 |
757 |
1 |
– |
1 |
Notepad |
38 |
220 |
– |
– |
– |
WSL (Ubuntu) |
– |
– |
– |
1 |
1 |
Примечание
Start time - время в секундах с начала открытия файла до появления текста в редакторе
RAM - аналогично Tаблице 1
Count - выводит только количество совпадений удовлетворяющим условиям поиска
Simple Search- время в секундах для поиска строки "340170317_134134587" во всем файле. В Notepad++ эта функция называется "Find All in Current Document". В результатах поиска должны выводиться детали о найденных совпадениях. В TextPad для этого использовалась функция "Find in Files". В Atom такая функция отсутствует. В Notepad поиск не тестировался
Regex search - Аналогично Simple Search, но поиск идет по регулярному выражения "340170317_\d{8}7"
Тестируем файл размером 1 Гбайт
Таблица 3 – поиск по файлу размером 1 Гбайт
App |
Start time |
RAM |
Count |
Simple Search |
Regex search |
Notepad++ |
2 |
1165 |
4 |
4 |
8 |
TextPad |
12 |
349 |
5 |
13 |
13 |
Atom |
8 |
2619 |
1 |
– |
2 |
Notepad |
452 |
2147 |
– |
– |
– |
WSL (Ubuntu) |
– |
– |
– |
5 |
5 |
Примечание
Start time, RAM,Count, Simple Search, Regex search - аналогично Tаблице 2
При большем размере файла удается наблюдать несколько интересных моментов. Из приятного, после 7 с лишним минут (452с) Notepad все же смог открыть файл, хотя на всё это время он, как и положено, ушёл в себя и не отвечал.
Быстрее всего файлы открывает Notepad++, при этом демонстрирую средние показатели по времени поиска.
TextPad, относительно других, работает не торопясь, но и оперативы требует не много.
Atom отличается молниеносным поиском, но требует оперативы в разы больше чем размер файла.
Поиск по директории
И финальный тест – поиск по директории. В директории 10 файлов по 100 Мбайт. Общий объем 1 Гбайт.
Таблица 4 – поиск по директории
App |
RAM |
Simple Search |
Regex search |
Notepad++ |
220 |
6 |
11 |
TextPad |
14 |
13 |
14 |
Atom |
401 |
6 |
6 |
WSL (Ubuntu) |
– |
6 |
6 |
Примечание
RAM,Simple Search, Regex search - аналогично Tаблице 2
В данном сценарии уже не так важен сам редактор, как взаимодействие с жёстким диском.
Место для выводов
Очевидно, что разные приложения по разному работают с текстовыми файлами. На файлах больших размеров или при поиске в директории это становится особенно заметно.
Похоже, стандартный Notepad читает файл одним потоком, поэтому делает это долго, в плане оперативы “дорого” и интерфейс его не отвечает во время открытия файла.
Notepad++ загружает файлы быстро, поиск делает быстро, но и памяти потребляет соизмеримо размеру файла.
TextPad наименее требователен к объему оперативной памяти, но времени на открытие файла (очевидно для его преобразования в меньший объём) тратится в разы больше.
Atom файл открывает не быстро, оперативы потребяет в разы больше размера файла, но время поиска уже в открытом документа – самое лучшее.
Что касается общего итога, похоже, лучшего редактора ещё не придумали и каждая из рассмотренных программ решает задачи по своему. С другой стороны, стоит отдельно отметить стандартный Блокнот, который для работы с логам не подходит совсем.
Сравнивая Notepad++ и TextPad, я всё же выбираю Notepad++, однако, делаю это больше по привычке и личным предпочтениям.
Комментарии (79)
Taraflex
27.07.2022 05:17+4Среди «блокнотов» для просмотра логов из живых альтернатив лучшее что находил
github.com/variar/klogg
crawlingroof
27.07.2022 07:40я такой пользуюсь, посмотрю на вашу, спасибо
https://github.com/zarunbal/LogExpert/
gimntut
28.07.2022 15:43Добавлю. В klogg есть крутейшая фича, которой я не видел в других программах, разве что в шедеврах от sysinternals.
К примеру можно найти все строки в которых есть "Error", но нет "Super Error"
https://klogg.filimonov.dev/docs/news/boolean_combination/
orekh
27.07.2022 05:23+2
ivshinslava Автор
27.07.2022 05:53А вот это грустная новость. Мне нравилось его для заметок использовать. Правдка с тех пор, как иногда работаю за ноутом с 16 Гб оперативы, стараюсь все эти программы вроде Atom, Teams, Outlook и Zoom не открывать =)
Semigradsky
27.07.2022 10:48+4Вместо Atomа бы Visual Studio Code протестировать. По ощущениям - куда быстрее Atomа.
QuAzI
28.07.2022 11:22+1Для заметок лучше какой-нибудь Obsidian, QOwnNotes... Atom на фоне тех же VSCode, vim, notepad++ - бессмыссленный и мёртвый проект.
Да и статья какая-то странная изначально. Большой лог-файл? grep, vim, F3 в любимом FM.
Но вообще-то лог обычно далеко не один, плюс хочется выкусить что-то в моменте и тогда
чиппендейлgrep, lnav, multitail, для куба stern во всю, если не прикручен какой-нибудь ELK/NewRelik... никогда даже не задумывался о таком изврате, как использование Atom для сколь-нибудь продуктивной работы вообще и тем более для разгребания больших логов
TyVik
27.07.2022 06:14+13А где Sublime text и какой-нибудь vim?
ProgMiner
27.07.2022 10:26+1Как это "какой-нибудь vim"? Передовой инструмент для работы с большими объёмами текста! Особенно, если смотреть на потребление памяти и скорость работы при огромном наборе функций.
isden
27.07.2022 11:05+1vim
На самом деле не очень. Ему становится очень грустно от текстового файла на пару сотен мегабайт.
TyVik
27.07.2022 13:01Под "какой-нибудь" я имел ввиду vi, vim, neovim, gvim и т.п.
vi, кстати, лучше всех справляется с просмотром логов (на мой взгляд).
isden
27.07.2022 11:06+1Еще можно добавить vs code. Говорят он в последних версиях стал очень неплох в плане скорости работы с большими файлами.
artalar
27.07.2022 12:22vscode хорошо ищет, но плохо открывает большие (десятки тысяч строк) файлы. Если файлов очень много и они не огромные - может подойти.
Kekmefek
27.07.2022 06:29+4Рекомендую попробовать так же Geany и neovim/vim.
Geany является весьма не плохой заменой Notepad++ на Linux, хотя для винды так же еть сборки. Поддерживает плагины. Все написано на C++.
Aquahawk
27.07.2022 06:53+3Советую автору изучить тему утилит командной строки из юникс систем, благо на винду они все ставятся сейчас без проблем https://habr.com/ru/post/267697/
ivshinslava Автор
27.07.2022 07:15Спасибо! Правда, тогда нужно уже будет сравнивать не текстовые редакторы, а разные наборы команд, видимо.
mumische
27.07.2022 08:13-1Зачем, если есть Powershell?
Aquahawk
27.07.2022 08:20затем что powershell есть только на windows. Ну и мне лень приводить примеры где powershell аналоги древних никсовых тулов будут драматически медленнее чем оригиналы.
mumische
27.07.2022 08:26+1Здрасьте, приехали.
https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-linux?view=powershell-7.2
Приведите лучше пример, как вы события в evt/evtx на удалённой машине древними юниксовыми утилитами грепаете.
AlexGorky
27.07.2022 09:27Я анализировал 2..3 Гб логи (это за 1 час работы). Скрипт на Powershell при поиске regexp-строки в текстовых логах nginx показал худшие результаты, чем скрипт на wshell.vbscript.
mumische
27.07.2022 09:35Как уже заметили выше, статья исключительно про скорость грепанья в текстовых файлах. Соглашусь, что упоминание powershell в данном контексте не вполне уместно. Про всякие там логстэши и прочие лог аналитиксы даже заикаться не следует.
weirded
27.07.2022 08:41+3Было бы любопытно дополнить бенчмарки для грепа.
Воспользуйтесь для замеров утилитой time (которую надо отдельно доустановить, не ту, которая built-in в shell)./usr/bin/time grep "hi" java_error_in_PYCHARM_3828.log 0.00user 0.00system 0:00.00elapsed 100%CPU (0avgtext+0avgdata 2784maxresident)k 0inputs+0outputs (0major+113minor)pagefaults 0swaps2784k - потребление памяти, как правильно интерпретировать все эти циферки с временем я ещё сам не разобрался.
ivshinslava Автор
27.07.2022 09:15Я уже наметил несколько утилит, которые тут упоминали. С грепом тоже попробую. Только момент по поводу результатов вызова grep - результаты поиска всё же далеки от того, что Notepad++ показывает в отфильтрованных (после запуска Find all in open document)
Sild
27.07.2022 12:13А чего там разбираться?
real - реально потраченное время (почему-то оно у вас откушен этот префикс). Wall-clock, как пишут в гайдах.
user - время в user-space (вам не надо)
sys - время в ядре (вам не надо)
Всякие нюансы типа "user и sys считает процессорное время и в случае многопоточных приложений может превышать real" - в данном случае тоже не важно
miksoft
27.07.2022 09:14+1В таких обзорах зачастую не хватает ещё одного фактора - способности открыть большой файл (хотя бы 4-8 ГБ) и, как подвариант, открыть файл размером более оперативной памяти.
Вот Notepad++ такое не умеет. Приходится пользоваться FAR-ом, хотя в целом он менее удобен для меня.
vconst
27.07.2022 10:50+1Открыть файл больше размера оперативки? Любопытно, кстати
Файлы в несколько гигов мне больше всего понравилась открывать www.emeditor.com
Очень быстро с ними работает и хорошо ищет текст в них, включая rxvconst
27.07.2022 11:3520 гиговый (при 16 набортной) — открывал минут 10. Но память засрана игрушками и тп висящими в фоне. Но с файлами по 1-5 гигов — просто летает
cahbe
27.07.2022 09:30А кто может подсказать программы действительно для чтения\анализа логов? Очень круто искать по 150 метровому логу строку, но если "вдрук" ты не знаешь что искать, и искать нужно нестандартности, было бы приятнее делать это в программах которые могут на это как-то указать, а не 600к строк глазами бежать в надежде уловить какие-то ужасы.
Может бывают какие-то программы которые сразу подсветят все "эрор" или "акес дынайд", повторяющиеся строки, или которым можно задать направленность лога (почта, веб иис\апач\джинскс,) и они в удобном виде выведут все "шероховатости"?
Понимаю что трусеньёры всё делают грепом, а что бы не ловить разночтений прямо в двоичном коде всё считывают, но вдруг есть те кому приятнее в графическом окружении работать.
ivshinslava Автор
27.07.2022 09:48В Notepad++ можно сделать свою подсветку (Language -> User defined language).
С другой стороны, когда уже с логом работаешь, очень удобно подсвечивать нужный текст: текст выделяется, пкм->Style token. После этого строка (слово), кот было выделено будет подсвечено во всём документе.
Inine
27.07.2022 11:29Я так пробовал, но такая подсветка адово тормозит на больших файлах. Я правда на виртуалках проверял, а не на серьезном железе.
DikSoft
27.07.2022 10:06Может бывают какие-то программы которые сразу подсветят все "эрор" или "акес дынайд",
CMTrace.exe из поставки Microsoft SCCM попробуйте.
DikSoft
27.07.2022 10:14Или если нравится что-то посвежее, то теперь там же есть CMPowerLogViewer.exe ( One Trace ) ставится из ConfigMgrSupportCenter.MSI
UnclShura
27.07.2022 10:13+4Вообще говоря автор занался откровенно не тем. Вот смотрите: логи большие, по-этому открывать их именно в редакторах - это использовать редактор не по назначению. От этого и проблемы типа "файл слишком большой" и "долго открывается". Для просмотра надо пользоваться (неожиданно!) просмотрщиком. Он не грузит файл в память и открывает все мгновенно. Однако лог - информация структурированая. И использовать просто просмотрщик - это терять структуру. Просмотр части лога - это занятие от безисходности, когда нормальные инструменты помочь не могут.
Какие нормальные? Это конечно-же индексаторы логов - Splunk, ElasticSearch и что там еще появилось. В Splunk можно писать довольно сложные запросы, которые сделают всю работу за вас - нечего глаза на логах ломать. Это вам не grep! Это нормальный язык работы с именно логами. Если Splunk'у помочь и немного разметить сообщения (я не люблю логи в Json - я все еще иногда их глазами читаю), то он может выделять значения, агрегировать, строить условия. И на худой конец можно посмотреть кусок сырого лога выше/ниже выбранной строки. А еще он агрегирует логи со многих машин и можно следить за распределенными транзакциями.
Читать логи редактором? Фу!
cepera_ang
27.07.2022 10:43+1Splunk и ElasticSearch как альтернатива «ПКМ -> Открыть с помощью» это конечно правильно, но всё равно как-то забавно :)
UnclShura
27.07.2022 10:48Ну не знаю. У меня нескольго гигабайт ротируемых логов с примерно 20 хостов и по 7-8 сервисов на каждом. Что тут ПКМ->Открыть?
Sergey1124
27.07.2022 11:02Splunk и ElasticSearch - это, конечно, хорошо, но индексаторы логов помогут только если они установлены на сервере. Бывают ситуациии когда логи приходят в виде файлов, тогда нужны просмотрщики логов, а не индексаторы.
isden
27.07.2022 11:11Можно попробовать загнать логи в базу sqlite, и уже там делать извращенные выборки.
UnclShura
27.07.2022 12:38Ну так просмотрщики, не редакторы-же. Автор рассматривает редакторы общего назначения, что на мой взляд не верно. Если лог такой маленький что лезет в редактор, так и смотрите его FAR'ом или абсолютно любым другим редактором. А то начинается "долго стартует", "не может загрузить" и т.д. :)
ivshinslava Автор
27.07.2022 12:50Спасибо, что переживаете, чем я занимаюсь =) Ваш подход конечно на голову серьёзней, но в моей работе есть несколько моментов, когда приходится логи крутить руками. Вот в такие моменты мне интерфейс и удобство работы кажутся важными моментами.
Да, Киабана тоже есть, но не все логи там доступны, к сожалению.
Sergey1124
27.07.2022 10:57Может бывают какие-то программы которые сразу подсветят все "эрор" или "акес дынайд",
Могу порекомендовать https://github.com/sevdokimov/log-viewer , может фильтровать записи по Severity, кликаете "Error" и видите только записи с severity=error. Так же можно скрыть неинтересные записи, если они зафлудили лог. Выделяете текст на не нужной записи и нажимаете "Скрыть записи с таким текстом".
Chloroform
27.07.2022 09:43+1Я использую glogg. Мне вполне нравится. Жаль не увидел в списке сравнения
zooks
27.07.2022 09:50Софт в тесте, мягко говоря, не самый актуальный. Когда тестировал редакторы на открытие 600 МБ файла, хорошо себя показали Sublime Text и неожиданно VS Code, а Atom завис.
Куда удобнее под Windows запустить WSL и использовать нормальный человеческий терминал.
xnike
27.07.2022 09:52
FSA
27.07.2022 09:56+1Когда посмотрел на заголовок, почему-то сразу вспомнился journald. Можно получить интересующий фагмент логов, а потом уже оп нему сделать нужный grep, если нужно. Если нет тонны текстовых файлов, то и поиск становится проще. К тому же и место на диске экономится и подробнее информация о событиях сохраняется.
NAI
27.07.2022 10:03+2Изначально я пытался использовать меню “Открыть с помощью” из проводника, так как чаще всего логи открываю именно так.
??? Самое частое это дабл-клик по файлу или перетаскивание в окно. И тут время открытия файла выходит на первое место.
Ну а вообще, зачем открывать лог на овердофига строк, потом его парсить, если можно сразу парсить (да еще и пачку файлов)?
wsl > grep -r "Jul 25 04:" .../log/ > full_log.txt
и вуаля мы имеем файл со всем что происходило в 4 утра 25 июля.
Да, это будет работать если 1 запись - 1 строка. Для всего остального надо добавлять или -А или -B.
cepera_ang
27.07.2022 10:03А теперь сделайте поиск с помощью rg (он же ripgrep выше) нативно из винды. Хотя там конечно оптимизации работы с несколькими файлами, по обходу папок и игнору ненужных файлов, поэтому на одном файле разницы должно быть не много и должно упереться в скорость ввода-вывода, а на втором запуске вообще из кеша — вот тут и будет понятно, что быстрее всего ищет :)
AlexeevEugene
27.07.2022 10:09+1Кстати у MS есть классная штука для просмотра логов - CMTrace. Это часть system center 2012 r2 configuration manager toolkit. Это маленький exeшничек, который сильно упрощает просмотр живого потока событий.
Sergey1124
27.07.2022 10:52+2Не могу не заметить что есть специализированные программы именно для просмотра логов, например вот: https://github.com/sevdokimov/log-viewer. Она может мгновенно открывать файл любого размера, не тратя много памяти, потому что читает только ту часть лога, которая отображается в данный момент. Определяет формат лога и подсвечивает некоторые поля, чтобы было удобнее читать. Так же позволяет открыть несколько логов в одном view, записи будут смёржены по таймстемпу.
entze
27.07.2022 11:00+2
kostushka
27.07.2022 13:25Плюсы Notepad++ :
Может искать по регуляркам и спец. символам (\n \r \t и т.д.)
Может искать по всем открытым файлам
Может подсвечивать и помечать найденное по тексту
Может считать число найденных вхождений (очень удобно для подсчета объектов)
gdt
27.07.2022 16:06+1Пользуюсь Notepad++ исключительно из-за его супер-невероятного Find All, как раз для просмотра не очень больших логов (меньше 100Мб). Что-то похожее есть в Visual Studio конечно, но по ресурсам вообще несоизмеримо. Для кодинга, скриптинга может и есть редакторы гораздо интереснее, но не в этом случае.
PaulZi
28.07.2022 01:10+1Listener из Total Commander тоже очень неплохо выполняет открытие и поиск по большим файлам, как и в FAR он не загружает весь файл в память.
NightShad0w
28.07.2022 21:32+1Из быстрых текстовых редакторов под Windows раньше пользовался Bred 3.0.3 который похоже застрял в развитии, и теперь BowPad. Быстро запускается, разумно большие файлы открывает без проблем, есть подсветка вхождений строки в тексте даже без использования поля поиска.
Под MacOSX пользовался TextMate, пока не открыл для себя BBEdit. Не то чтобы инструменты специально для логов, но для быстрого и частого инспектирования текстовых и не очень файлов размера до нескольких гигабайт норм.
eugenex15
28.07.2022 21:59+1рекомендую обратить внимание на CudaText
после Sublime, Notepad++ и т.д. использую CudaText, nvim (spacevim), VSCode.
PS
CudaText is a cross-platform text editor, written in Object Pascal. It is open source project and can be used free of charge, even for business. It starts quite fast: ~0.3 sec with ~30 plugins, on Linux on CPU Intel Core i3 3GHz. It is extensible by Python add-ons: plugins, linters, code tree parsers, external tools. Syntax parser is feature-rich, from EControl engine.
PPS CudaText VS other editors тут про производительность.
entze
29.07.2022 13:43Более сложная задача, чем просмотр логов - просмотр XML. Тут https://xmlexplorer.github.io в помощь.
neco
а почему нету FARа в сравнении?
saboteur_kiev
Мало того, что нет FAR, так еще и такой подход как поиск в логах, вместо фильтрации и просмотра уже результата поиска.
ivshinslava Автор
Тут видимо у меня сложности перевода. Изначально конечно хочется отфильтровать лог, и потом уже с результатми работать. Именно этот сценария я и рассматривал. Добавлю этот момент в статью.
В Notepad++ эта функция называется "Find all in current document".
saboteur_kiev
Тут прикол в том, что сперва notepad++ откроет документ, а принцип работы РЕДАКТОРА с плейн текстом в основном в том, что он все грузит в память, а потом фильтрует.
Если же фильтровать предварительно каким-нить grep, который читает файл построчно, не аллоцирует гигабайты памяти, то в редактор попадет уже маленький кусочек.
Ну то есть это реально принципиальное различие, кто и когда фильтрует данные. Нужно ли их фиьтровать повторно, как часто. От этого и зависит инструмент.
Можно grep blabla | less, можно less и там +F.
ivshinslava Автор
FAR именно для поиска я не использовал. Открывает он большие файлы и правда быстро. Он умеет выводить все совпадения для искомой строки? Я файл открыл и он только по порядку результаты показывает.
Если использовать Find file, то он только название файла выдает, где строка найдена (нет кол-ва)
Geckelberryfinn
Для подсчёта можно заменить все вхождения, если мне память не изменяет, то он сообщит, сколько он замен сделал. А потом не сохранять.
Неоспоримым достоинством FAR является то, что он может открыть файлы достаточно большие, чтоб Notepad++ сообщил "File too big to open". Попробуйте на 40Гб файле, например.
freeExec
Потому что он их не открывает в привычном смысле для редакторов текста. Он их просматривает, и по сути памяти требует только чтобы хватало на текст что на экране.
cepera_ang
Редактор тоже может так делать, в принципе :)
freeExec
Кто чего не может, не понял?
В Фар две кнопки — F3 и F4. Чтобы найти все строки достаточно использовать просмотр по F3.
cepera_ang
Редактор тоже может загружать в память только секцию, которая отображается на экране.
ivshinslava Автор
Да, вижу "Find All". Но эта фича доступна только когда открываю файл через F4 (на редактирование). Если открывать через F3 (на чтение), то поиск работает, но находит только первое совпадение
smind
Плагин для поиска и замены в текстовом редакторе FAR. Заменяет стандартные функции Поиск и замена рядом повышенной способности: * Настраиваемые режимы выделений и выделений * Выделение всех найденных вхождений * Быстрый поиск выявленных слов * Циклический поиск/замена * Выявление всех найденных вденподобных в едином списке * Подсчет количества вхождений
Обсуждение:
http://forum.farmanager.com/viewtopic.php?f=5&t=5098
saboteur_kiev
в фаре это можно вот так:
edit:<<grep "mystring" file.txt