Но, справедливости ради, кривые руки завсегда победят даже очень хороший стек технологий. Об этом и пойдет сегодня речь.
Сто лет как пользуюсь Notepad++, это бесплатный, функциональный, легковесный и очень быстрый редактор текста с фичами для программистов. Как бы быстрый, ибо есть одна оговорка. Функция поиска текста по множеству файлов работает с совершенно черепашьей скоростью. Если взять за референс аналогичную функцию в Total Commander (где она, судя по всему, реализована максимально прямолинейно, без всяких там фокусов имени Бойера-Мура), то Notepad++ делает это как минимум на порядок медленнее.
Понятно, что речь идет о поиске по данным на диске, доступ к которым, конечно же, может быть узким местом. Но у меня по работе часто бывает, что при рефакторинге многократно ищешь что-то в одном и том же, относительно компактном, наборе файлов, который гарантировано будет закэширован операционной системой в память.
Первая мысль, которая возникла в голове по поводу этой тормознутости — ну окей, вы написали свой алгоритм поиска по тексту несколько криво, но сейчас 22-й год на дворе, у всех давно стоят многоядерные процессоры, запустите его параллельно по этим ядрам и получите многократный прирост на ровном месте. Для сферического текстового редактора в вакууме такую переделку можно реализовать за несколько дней работы... Пошел гуглить по теме и узнал много чего интересного. Потом таки скачал исходники Notepad++ и ошарашенный очень долго приходил в себя. Тут получилось как иной раз с красивой женщиной — восхищаешься ее задницей ровно до того момента, пока она не откроет рот.
Код написан на C++ в жестко непортируемом стиле с активным использованием Win32 API. Ну как бы хрен бы с ним: хочешь писать только под одну платформу — пиши себе, вопрос только в том, насколько грамотно ты будешь проектировать свой код и делать вещи, типа отделения бизнес логики от представления. Так вот, исходники Notepad++ это просто Содом и Гоморра, поток сознания, бесконечные костыли и потекшие абстракции. Там просто нет живого места.
А теперь про реализацию поиска в этом чуде. Поиск это функция визуального текстового компонента со всеми вытекающими из этого последствиями. Поэтому для поиска текста по нескольким файлам программа держит невидимым этот текстовый компонент-редактор, в который грузится текущий файл и для которого потом вызывается непосредственно функция поиска. Очевидно, что работает это до невозможности медленно и ни о какой легкой возможности все это распараллелить и речи быть не может. Там даже диалог прогресса этого поиска сделан на таких соплях, что сразу хочется с воем убежать куда-то в сторону леса.
А на противоположном полюсе от Notepad++ у нас сегодня будет Visual Studio Code, "приложение", написанное под горячо любимый многими Electron. Тут поиск реализован людьми с прямыми руками, которые сделали его многопоточным и на процессоре с 6C/12T получили пятикратный выигрыш против Total Commander'а.
Вот вам и весь сказ!
И в качестве удивительного бонуса, поделюсь еще с вами результатами другого старичка — Visual Studio. Эта IDE использует многопоточность при поиске, но при этом умудряется показывать результаты, существенно худшие, чем TC. Как тут программисты Microsoft умудрились напортачить — хз, но, судя по всему, эти ребята тоже что-то там грузят в невидимую компоненту для редактирования текста...
зы. Результаты бенчмарков на ноутбуке с i7 10850H. Исходники Chromium, поиск строки "sandbox" по файлам *.h*;*.c* (коих набирается почти 1 Гб):
А теперь про реализацию поиска в этом чуде. Поиск это функция визуального текстового компонента со всеми вытекающими из этого последствиями. Поэтому для поиска текста по нескольким файлам программа держит невидимым этот текстовый компонент-редактор, в который грузится текущий файл и для которого потом вызывается непосредственно функция поиска. Очевидно, что работает это до невозможности медленно и ни о какой легкой возможности все это распараллелить и речи быть не может. Там даже диалог прогресса этого поиска сделан на таких соплях, что сразу хочется с воем убежать куда-то в сторону леса.
А на противоположном полюсе от Notepad++ у нас сегодня будет Visual Studio Code, "приложение", написанное под горячо любимый многими Electron. Тут поиск реализован людьми с прямыми руками, которые сделали его многопоточным и на процессоре с 6C/12T получили пятикратный выигрыш против Total Commander'а.
Вот вам и весь сказ!
И в качестве удивительного бонуса, поделюсь еще с вами результатами другого старичка — Visual Studio. Эта IDE использует многопоточность при поиске, но при этом умудряется показывать результаты, существенно худшие, чем TC. Как тут программисты Microsoft умудрились напортачить — хз, но, судя по всему, эти ребята тоже что-то там грузят в невидимую компоненту для редактирования текста...
зы. Результаты бенчмарков на ноутбуке с i7 10850H. Исходники Chromium, поиск строки "sandbox" по файлам *.h*;*.c* (коих набирается почти 1 Гб):
Total Commander (single threaded): 35 sec
Notepad++ (single threaded): 446 sec
Visual Studio Code (multi-threaded): 7 sec
Visual Studio 2017 (multi-threaded): 48 sec
Notepad++ (single threaded): 446 sec
Visual Studio Code (multi-threaded): 7 sec
Visual Studio 2017 (multi-threaded): 48 sec
зы2. VS Code, безусловно, заметно похорошел с той поры, когда я его последний раз щупал. Но, блин, от этого уебищного json файла с настройками они пока что сделали только пол шага в нужную сторону. Оцените, к примеру, как весело предлагается выставить один из главных параметров редактора -- шрифт:
Товарищи рукожопы, если я пожелаю заниматься подобным онанизмом, то я сразу пойду в vim. Я не веб-дизайнер, я не знаю, какими заклинаниями я должен устанавливать нужный мне фонт. В нормальном визуальном редакторе шрифт при выборе должен полностью визуализироваться! Уловили идею?
No comments:
Post a Comment