А в CLion и JSX-исходниках в Райдере всё сильно печально.
В CLion, например, нажимая CTRL-пробел в пустой строке или открывая скобку после имени функции жуткие тормоза. Это в маленьком проекте.
Так же в Райдере в JSX-исходниках.
При этом видно что всего один поток из восьми загружается
Будет вот это безобразие "многопоточится"?
Домашний проц с одной стороны старый — Ivy Bridge 1270, но с другой стороны 3.7 Ггц в восьми-потоке и 3.9 Ггц в турбо-бусте в однопотоке. Ну и современные U-процессоры в ноутбуках не быстрее что от интел что райзены. Так что тема актуальная.
____
Если есть такой тикет поделитесь ссылкой. Проголосую и почитаю.
Здравствуйте, hmich, Вы писали:
H>Ответ очевиден — пока нет, т.к. для интеллисенса используется clangd, а C++ компиляторы не параллелятся.
Разумеется это неверное утверждение.
Параллелятся/непарралелятся алгоритмы и операции над структурами данных.
Если fuzzy-логика интеллисенса в нестрого типизированных языках подразумевает выборку из большого-большого dictionary, то это парралелится когда используется B-дерево или бинарный поиск.
VC>В CLion, например, нажимая CTRL-пробел в пустой строке или открывая скобку после имени функции жуткие тормоза. Это в маленьком проекте. VC>Так же в Райдере в JSX-исходниках.
VC>Если есть такой тикет поделитесь ссылкой. Проголосую и почитаю.
Сначала сразу скажу, что в идеале было бы засабмитить пример в трекер, на котором это воспроизводится. Ну, или хотя бы CPU snapshot. Такие тормоза случаются (к сожалению) и зависят сильно от проекта (и даже не его размера, а сложности языковой). Пример будет очень полезен.
Почему это происходит и при чем тут однопоточность? Я не могу утверждать наверняка, не видя примера кода. Но чаще всего такое случается, когда платформенный action (в данном случае какое-нибудь форматирование или подсветка или что-то еще из typing assist) запрашивает у языкового движка нечто про код, что внезапно требует резолв кода. К сожалению, в отличие от Java или Python, в C++ резолв может потребоваться для всего чего угодно (даже покрасить код без него нельзя правильно). И получается, что action, который по расчетам платфорфмы должен был быть быстро выполнен в текущем потоке, вдруг затребовал чуть ли не репарс всего (редко совсем так плохо, но всякое бывает).
Что мы с этим делаем? Конечно, не смотрим на это спокойно и уже давно приоритезировали такие проблемы выше всего остального. Но фиксить их точечно невозможно — это требует скорее глобальной переделки архитектуры платорфмы. Или же (и именно такой пусть мы сейчас выбрали) переведения части action-ов на clangd-движок (с каждым релизом туда все больше штук переезжает), а то, что не возможно (потому что там нет индекса всего проекта) на какую-то lightweight модель кода. С последним пока сложно, потому что никак не найти золотой середины между "легко/быстро" и "правильно хотя бы почти всегда". Но мы в процессе.
Зачем же вам тогда мой пример кода? Ну например, потому что иногда случаются low-hanging fruits, которые можно как-то быстро все же убрать и без глобальных переделок.
Здравствуйте, anastasiak2512, Вы писали:
VC>>В CLion, например, нажимая CTRL-пробел в пустой строке или открывая скобку после имени функции жуткие тормоза. Это в маленьком проекте. VC>>Так же в Райдере в JSX-исходниках.
VC>>Если есть такой тикет поделитесь ссылкой. Проголосую и почитаю.
A>Сначала сразу скажу, что в идеале было бы засабмитить пример в трекер, на котором это воспроизводится. Ну, или хотя бы CPU snapshot. Такие тормоза случаются (к сожалению) и зависят сильно от проекта (и даже не его размера, а сложности языковой). Пример будет очень полезен.
A>Почему это происходит и при чем тут однопоточность? Я не могу утверждать наверняка, не видя примера кода. Но чаще всего такое случается, когда платформенный action (в данном случае какое-нибудь форматирование или подсветка или что-то еще из typing assist) запрашивает у языкового движка нечто про код, что внезапно требует резолв кода. К сожалению, в отличие от Java или Python, в C++ резолв может потребоваться для всего чего угодно (даже покрасить код без него нельзя правильно). И получается, что action, который по расчетам платфорфмы должен был быть быстро выполнен в текущем потоке, вдруг затребовал чуть ли не репарс всего (редко совсем так плохо, но всякое бывает).
A>Что мы с этим делаем? Конечно, не смотрим на это спокойно и уже давно приоритезировали такие проблемы выше всего остального. Но фиксить их точечно невозможно — это требует скорее глобальной переделки архитектуры платорфмы. Или же (и именно такой пусть мы сейчас выбрали) переведения части action-ов на clangd-движок (с каждым релизом туда все больше штук переезжает), а то, что не возможно (потому что там нет индекса всего проекта) на какую-то lightweight модель кода. С последним пока сложно, потому что никак не найти золотой середины между "легко/быстро" и "правильно хотя бы почти всегда". Но мы в процессе.
A>Зачем же вам тогда мой пример кода? Ну например, потому что иногда случаются low-hanging fruits, которые можно как-то быстро все же убрать и без глобальных переделок.
A>Много написала. Надеюсь, стало понятнее.
Т.е. парсинг и прочий анализ откладывается пока пользователь не начнет вводить код или не попросит движок typing assist?
А нельзя ли лениво эту работу в фоне начать, пока пользователь просто смотрит в tab с исходником или скроллит? Вы же для раскраски синтаксиса лениво анализируете, наверно там и анализ для type assistant можно запускать? На вид это же всё в рамках архитектуры видится.
И как/чем снять CPU Snapshot и какого именно процесса для JSX (Rider) и C/C++ исходников (CLion)?
VC>Т.е. парсинг и прочий анализ откладывается пока пользователь не начнет вводить код или не попросит движок typing assist?
VC>А нельзя ли лениво эту работу в фоне начать, пока пользователь просто смотрит в tab с исходником или скроллит? Вы же для раскраски синтаксиса лениво анализируете, наверно там и анализ для type assistant можно запускать? На вид это же всё в рамках архитектуры видится.
Резолв самого нужного случается сразу, остальное откладывается "пока не понадобиться". Вообще резолв довольно тяжелая штука, если мы постоянно в фоне будет резолвить код, которые может пользователь вообще никогда не откроет, будет большой CPU usage без толку. К тому же, тайпинг — очевидно меняет код. Так что что-то приходится и налету репарсить и еще как-то при этом (в отличие от компилятора) восстанавливаться от ошибок. В целом, это все понятные алгоритмы, но накладываются на C++ они местами со скрипом. И кое-где мы пытаемся что-то совсем новое сделать сейчас.
VC>И как/чем снять CPU Snapshot и какого именно процесса для JSX (Rider) и C/C++ исходников (CLion)?
