Здравствуйте, 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 и C/C++ исходников?

Здравствуйте, 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)?