Можете поподробнее рассказать про проблему? Если не сильно лень, то заведите пожалуйста реквест на трекере youtrack.jetbrains.com/issues/RIDER, попробуем выяснить что не так работает
Я ни разу вас не уговариваю уйти со студии. Если вам хорошо разрабатывать в студии, то это отлично. Просто не стоит в каждом фризе студии винить решарпер, есть куча причин по которым оно может тормозить, но, я заметил, пошла такая мода, в случае любого подвисания студии все стрелки переводить на «тормозной убогий решарпер»
В кейсе написано, что у меня R# медленнее раз в 100-1000. Про асинхронность тоже не совсем правда — CodeLens полностью асинхронный, а поиск решарпера заметно больше тормозит студию, потому что использует в 4 раза больше потоков, и периодически самоотменяется («Find Usages has been canceled» или что-такое). Может быть под поиском рослином вы что-то другое имеете ввиду, о чём я не знаю?
Я подождал 3.5 минуты для того, чтобы codelens показал мне кол-во ссылок на проперти Language. Это на машине core i7, 32gb ram. Впечатляющая производительность. Особенно если мне нужно найти референсы 5-10 раз подряд на разные символы. А в предыдущем комменте я говорил про экшн студии Find all references.
Потребление памяти 1 ГБ и растёт, а не уменьшается. Без решарпера не повторяется.
Так что из этого? Тормоза то, которые вы видите, порождаются от GC.Collect()
Потому что ну вот не верю я, что все ваши проблемы связаны с нехваткой памяти. Как-то же CodeLens умудряется влезать в 275 мегабайтов памяти (пусть и в отдельном процессе) и при этом мгновенно искать референсы по всему солюшену.
см. выше
Если оно будет хотя бы сравнимо по скорости с VS 2015 (или какая там будет на тот момент), то я куплю/продлю персональную лицензию и всерьёз рассмотрю возможность поддержки R# и/или Rider в компании
Отвечу отдельно по всем:
1) RSRP-448070 «Find Usages» speed depends on how common the name of searched item is
Да, это действительно так, множество файлов поиска зависит от того, какой идентификатор ищется. Т.е. если идентификатор Type встречается в 1000 файлах, то действительно поиск пройдет по всем этим файлам (конечно, если эти файлы достижимы по проектным зависимостям).
Я сейчас специально провел эксперимент, сделал поиск идентификатора Language, который встречается десятки тысяч раз в нашем проекте, с помощью решарпера и с помощью студийного поиска (который видимо уже на рослине):
а) Рослин — 1мин 3секунды, потребление памяти возросло на 800мб, блокирует на все время поиска окно студии
б) Решарпер — 28 секунд, потребление памяти возросло на 150мб, ищет асинхронно, можете делать параллельно, что угодно
Что же вам удобнее?
2)RSRP-447915 Opening «Add New Item» on a folder spins 1 CPU core 100%
Вам показали стектрейс, в котором явно видно, что факап студии. Да он возникает изза нехватки памяти, но это один из тех кусков кода, где в цикле вызывается GC.Collect(). (и такой кусок не один в студийном коде)
Как нам с этим бороться? да, мы пытаемся экономить память, но судя по всему, только мы этим и занимаемся
Кстати сам натыкался на этот факап много раз
3) RSRP-446534 «Find code dependent on module» freezes main VS window
Вероятно наш продолб, отрицать не буду. Просто редко использую эту фичу, сам не натыкался
4)RSRP-447853 Opening R# IntelliSense is a CPU-bound operation that does not scale with project size
Не отрицаю, что проблема есть, но сам не смог воспроизвести. Комплишен поднимается всегда. R# 10.0.2
5)RSRP-447916 Pasting anything into ascx/aspx files hangs VS for 20 seconds
Вроде бы вы вместе разобрались, что это баг не решарпера, и вопроизводится без решарпера вообще.
Т.е. из тех 5 перформанс проблем, что вы зарепортили, действительно наших — две, и по обеим из них вроде бы вы даже получили ответы.
Предлагается предоставлять опцию отключить рослин и все фичи, зависящие от него. Редактировать документ можно и без рослина. Подчеркну — это только для тех, кому роднее фичи решарпера. Однако, такой опции никто не предоставил.
Извините, но я разрабатываю решарпер около 3 лет и профилировал студию вместе с ним не одну сотню раз и знаю, о чем говорю. И сейчас я разрабатываю Райдер и тоже знаю, о чем говорю, сравнивая скорость работы студии и решарпера на одинаковых проектах. Решарпер далеко не идеален, но в студии гораздо более серьезные факапы, которые никто не собирается фиксить и на которые мы никак не можем повлиять, даже имея прямой контакт с разработчиками студии, слишком много бюрократии у MS. Я всего лишь пытаюсь возразить, что тормоза в студии с включенным решарпером далеко не всегда по вине самого решарпера, а по вине нехватки памяти в 32битном процессе. Если вам хорошо на Рослине, удалите решарпер и живите на рослине, однако на 300 проектах, рослин помирает и без решарпера. А если пользователь привык к решарперу, то выкат VS2015 вставляет ему большие палки в колеса изза невозможности отключить рослин и жить только с решарпером.
Вы уверены, что в VS 2015 умирает Решарпер? Умирает студия изза недостатка свободной памяти, которую очень хорошо выжирает «новый модный» Roslyn. Изза этого начинает работать Blocking GC, который тормозит UI поток студии. Решарпер тоже поедает память, хотя и не сильно много, но по крайней мере в нем нет кода подобного while (freemem < 300 * 1024 * 1024) { GC.Collect(); Thread.Sleep(100); }, а в студии есть.
Rider (работающий на решарпере), открывает солюшен ~300 проектов примерно в 2 раза быстрее, чем это делает студия. И во время открытия можно без проблем тайпить в документе в отличие от студии.
Для интереса, найдите солюшен в 300-400 проектов, откройте его в VS2015 и попробуйте найти наследников какого-либо часто наследуемого класса (с колвом наследников от 50), после этого студию с ее «инновационным» рослином придется убить
Есть ли возможность прикрутить родную синхронизацию от Chrome? Самое главное, что меня останавливает от использования оперы, это куча синхронизируемой информации в гуглосервсисах — пароли, закладки, сессии, экстеншены и т.д.
Да тут нет разговора о случайных и псевдослучайных числах. Понятно, что случайные числа никто не сгенерит.
Задача дана элементарная — сгенерить случайное число в заданном интервале. Единственный разумный тест, который можно на нее сделать — проверить результат на заданный диапазон, ну еще можно запустить в тесте решение несколько раз и проверить, что числа не повторяются (т.е. хотя бы примерно они случайные).
У автора же тест — это проверка на равенство случайного числа, сгенерированного ВАШЕЙ программой, с константой автора, которая вам неизвестна. Вопрос — НАХРЕНА?
В тесте к задаче нет возможности в цикле принять все тестовые вводы и посчитать результат. Цикл здесь приходится делать руками путем натыкивания кнопочки в браузере, что есть маразм чистой воды. Программирование должно учить оптимизации, а здесь абсолютно обратный пример идиотской траты времени.
Гениально. Дать задачу, которую надо решать тупым натыкиванием. Условие задачи предполагает, что она решается максимум за 2 минуты, я а на нее потратил около 2.5 часов. И вы думаете, что ребенок останется счастлив после таких задач? Судя по стате ее решили человек 5 в среднем со 150 сабмита. Чему эта задача научит? Угадывать рандом? Почему вы тогда не сделали на остальные задача рандомные тесты? пусть все угадывают.
>Кроме того, она рассчитана на некоторое чувство юмора и настойчивость.
за такое чувство юмора и ударить можно. Если вам не ценно ваше время, это не значит, что оно не ценно другим. Потратить 2.5 часа на 1 задачу одного предмета (более того, из формулировки ожидается, что она элементарная) — это трындец. Тем более, если вы ориентированы на детей, у которых в день по 4-5 предметов домашки и примерно 3-4 часа времени.
С какой стати кто-то должен понимать ваши «тонкие» намеки на хардкод в тесте на рандомный вывод? И вообще смысл этого всего? Чему вы научите этой задачей?
>Этот урок учит нестандартному подходу к решению задач.
Этот урок не учит ничему, а лишь тратит нервы и время.
Нестандартному подходу может научить только лишь хорошо прочитанный курс Алгоритмов и структур данных, много практики и правильные задачи.
Вы извините меня, но автору задач на videosharp.info хотелось настучать по морде, когда меня попросили их решить.
Написал знакомый, с просьбой решить несколько задач на этом сайте для его дочери, у которой в школе так принимают зачеты.
Можно закрыть глаза на то, что во многих задачах описанный формат ввода-вывода не совпадает с рабочим вариантом. Можно закрыть глаза на то, что нет конкретных примеров ввода-вывода (а между прочим его дают на абсолютно всех олимпиадных задачах).
Но следующее меня убило. Дана задача:
«ЗАДАЧА
Даётся натуральное число N, от 1 до 10.
Написать программу, которая генерирует случайное число от 1 до N и выводит его на экран.
Начальные данные: одно целое число от 1 до 10.
Вывод результата: случайное число из интервала.
В программе необходимо использовать класс Random.»
Хрен пойми интервал открытый, закрытый, полуоткрытый? Ладно, пишу типа new Random().Next(1, N). Не принимает. Ок, думаю гдето вышли за интервал. Подбираю всевозможные варианты интервалов — не работает.
Провозился минут 40 и понял, что код теста — это не проверка результата на интервал, а просто захаркоженные пары чисел!!! Ну как там можно?? В итоге методом подбора сидел ломал тесты и подбирал пары чисел. Один из вариантов в итоге пришлось написать стохастически и сидеть сабмиттить решение пока рандом не вывалит нужное число.
И как после такого можно доверить обучение этому сайту?
Вы лучше шлите снепшоты) будем разбираться. Решарпер конечно более нетороплив голой студии. Но и кол-во работы, которую он выполняет (анализы, подсветки, доступность экшенов и т.д.) раз в 100 больше, чем в студии. Если ту же функциональность попробовать поднять на коде комплилятора, то все умрет на проектах в 100 раз меньших, чем у вас.
Баг в TS посмотрим, спасибо! Но скажу следующее:
как уже написал ControlFlow, мы пишем поддержки языков на языке IDE, потому что это
а) позволяет писать легко поддерживаемый и легко отлаживаемый код.
б) позволяет писать производительный код, прерываемый, асинхронный код
Компилятор TS написан на TS и слабо удовлетворяет обоим требованиям.
Во-первых, для запуска TS (точнее JS) нужно отдавать код в какой-нибудь V8 или IE, при этом теряется возможность отладки того, что происходит внутри.
Во-вторых, этот код непрерываемый «по-хорошему», только убийством фонового потока, В Решарпере все анализы прерываются на тайпинг любого символа в документе, вывод типов может запрашиваться 100-1000 раз на каждое изменение документа, и почти всегда это работает мгновенно, чего не скажешь о студии, которая вешает хайлайтинги в TS документе с задержкой около секунды.
В-третьих, когда мы имплементируем поддержку TS (как и других языков), мы руководствуемся спекой. А у компилятора TS мы выявили немалое кол-во расхождений со спекой языка (и репортили баги, конечно же). Было немало случаев, когда логику работы компилятора мы понять не смогли вообще (она не сходилась со спекой) и в разных примерах компилятор выдавал неадекватные результаты, например в отношении сравнения рекурсивных генерических типов. Даже чтение кода компилятора к прозрению не приводило.
В-четвертых, код компилятора очень нестабильный в плане API, подстраиваться под него и разбираться в изменениях, особенно, когда взаимодействие между R# и TS комилятором не строготипизированное — очень тяжелая задача, сложность которой, зависит уже не от нас.
Есть еще много пунктов, почему мы имплементим поддержку языков сами. Да, расхождения случаются, но мы стараемся их фиксить по мере поступления баг-репортов.
Лучший комментарий! Моя мысли абсолютно такие же, когда вижу советы об обучении программированию на js, питоне и тд
насчет 2 — пока что есть более критичные баги. Не хочется обещать на ближайшее время. Да и UI там надо писать
Я подождал 3.5 минуты для того, чтобы codelens показал мне кол-во ссылок на проперти Language. Это на машине core i7, 32gb ram. Впечатляющая производительность. Особенно если мне нужно найти референсы 5-10 раз подряд на разные символы. А в предыдущем комменте я говорил про экшн студии Find all references.
Так что из этого? Тормоза то, которые вы видите, порождаются от GC.Collect()
см. выше
оно быстрее студии уже на данный момент
1) RSRP-448070 «Find Usages» speed depends on how common the name of searched item is
Да, это действительно так, множество файлов поиска зависит от того, какой идентификатор ищется. Т.е. если идентификатор Type встречается в 1000 файлах, то действительно поиск пройдет по всем этим файлам (конечно, если эти файлы достижимы по проектным зависимостям).
Я сейчас специально провел эксперимент, сделал поиск идентификатора Language, который встречается десятки тысяч раз в нашем проекте, с помощью решарпера и с помощью студийного поиска (который видимо уже на рослине):
а) Рослин — 1мин 3секунды, потребление памяти возросло на 800мб, блокирует на все время поиска окно студии
б) Решарпер — 28 секунд, потребление памяти возросло на 150мб, ищет асинхронно, можете делать параллельно, что угодно
Что же вам удобнее?
2)RSRP-447915 Opening «Add New Item» on a folder spins 1 CPU core 100%
Вам показали стектрейс, в котором явно видно, что факап студии. Да он возникает изза нехватки памяти, но это один из тех кусков кода, где в цикле вызывается GC.Collect(). (и такой кусок не один в студийном коде)
Как нам с этим бороться? да, мы пытаемся экономить память, но судя по всему, только мы этим и занимаемся
Кстати сам натыкался на этот факап много раз
3) RSRP-446534 «Find code dependent on module» freezes main VS window
Вероятно наш продолб, отрицать не буду. Просто редко использую эту фичу, сам не натыкался
4)RSRP-447853 Opening R# IntelliSense is a CPU-bound operation that does not scale with project size
Не отрицаю, что проблема есть, но сам не смог воспроизвести. Комплишен поднимается всегда. R# 10.0.2
5)RSRP-447916 Pasting anything into ascx/aspx files hangs VS for 20 seconds
Вроде бы вы вместе разобрались, что это баг не решарпера, и вопроизводится без решарпера вообще.
Т.е. из тех 5 перформанс проблем, что вы зарепортили, действительно наших — две, и по обеим из них вроде бы вы даже получили ответы.
Rider (работающий на решарпере), открывает солюшен ~300 проектов примерно в 2 раза быстрее, чем это делает студия. И во время открытия можно без проблем тайпить в документе в отличие от студии.
Для интереса, найдите солюшен в 300-400 проектов, откройте его в VS2015 и попробуйте найти наследников какого-либо часто наследуемого класса (с колвом наследников от 50), после этого студию с ее «инновационным» рослином придется убить
Да тут нет разговора о случайных и псевдослучайных числах. Понятно, что случайные числа никто не сгенерит.
Задача дана элементарная — сгенерить случайное число в заданном интервале. Единственный разумный тест, который можно на нее сделать — проверить результат на заданный диапазон, ну еще можно запустить в тесте решение несколько раз и проверить, что числа не повторяются (т.е. хотя бы примерно они случайные).
У автора же тест — это проверка на равенство случайного числа, сгенерированного ВАШЕЙ программой, с константой автора, которая вам неизвестна. Вопрос — НАХРЕНА?
>Кроме того, она рассчитана на некоторое чувство юмора и настойчивость.
за такое чувство юмора и ударить можно. Если вам не ценно ваше время, это не значит, что оно не ценно другим. Потратить 2.5 часа на 1 задачу одного предмета (более того, из формулировки ожидается, что она элементарная) — это трындец. Тем более, если вы ориентированы на детей, у которых в день по 4-5 предметов домашки и примерно 3-4 часа времени.
С какой стати кто-то должен понимать ваши «тонкие» намеки на хардкод в тесте на рандомный вывод? И вообще смысл этого всего? Чему вы научите этой задачей?
>Этот урок учит нестандартному подходу к решению задач.
Этот урок не учит ничему, а лишь тратит нервы и время.
Нестандартному подходу может научить только лишь хорошо прочитанный курс Алгоритмов и структур данных, много практики и правильные задачи.
Написал знакомый, с просьбой решить несколько задач на этом сайте для его дочери, у которой в школе так принимают зачеты.
Можно закрыть глаза на то, что во многих задачах описанный формат ввода-вывода не совпадает с рабочим вариантом. Можно закрыть глаза на то, что нет конкретных примеров ввода-вывода (а между прочим его дают на абсолютно всех олимпиадных задачах).
Но следующее меня убило. Дана задача:
«ЗАДАЧА
Даётся натуральное число N, от 1 до 10.
Написать программу, которая генерирует случайное число от 1 до N и выводит его на экран.
Начальные данные: одно целое число от 1 до 10.
Вывод результата: случайное число из интервала.
В программе необходимо использовать класс Random.»
Хрен пойми интервал открытый, закрытый, полуоткрытый? Ладно, пишу типа new Random().Next(1, N). Не принимает. Ок, думаю гдето вышли за интервал. Подбираю всевозможные варианты интервалов — не работает.
Провозился минут 40 и понял, что код теста — это не проверка результата на интервал, а просто захаркоженные пары чисел!!! Ну как там можно?? В итоге методом подбора сидел ломал тесты и подбирал пары чисел. Один из вариантов в итоге пришлось написать стохастически и сидеть сабмиттить решение пока рандом не вывалит нужное число.
И как после такого можно доверить обучение этому сайту?
как уже написал ControlFlow, мы пишем поддержки языков на языке IDE, потому что это
а) позволяет писать легко поддерживаемый и легко отлаживаемый код.
б) позволяет писать производительный код, прерываемый, асинхронный код
Компилятор TS написан на TS и слабо удовлетворяет обоим требованиям.
Во-первых, для запуска TS (точнее JS) нужно отдавать код в какой-нибудь V8 или IE, при этом теряется возможность отладки того, что происходит внутри.
Во-вторых, этот код непрерываемый «по-хорошему», только убийством фонового потока, В Решарпере все анализы прерываются на тайпинг любого символа в документе, вывод типов может запрашиваться 100-1000 раз на каждое изменение документа, и почти всегда это работает мгновенно, чего не скажешь о студии, которая вешает хайлайтинги в TS документе с задержкой около секунды.
В-третьих, когда мы имплементируем поддержку TS (как и других языков), мы руководствуемся спекой. А у компилятора TS мы выявили немалое кол-во расхождений со спекой языка (и репортили баги, конечно же). Было немало случаев, когда логику работы компилятора мы понять не смогли вообще (она не сходилась со спекой) и в разных примерах компилятор выдавал неадекватные результаты, например в отношении сравнения рекурсивных генерических типов. Даже чтение кода компилятора к прозрению не приводило.
В-четвертых, код компилятора очень нестабильный в плане API, подстраиваться под него и разбираться в изменениях, особенно, когда взаимодействие между R# и TS комилятором не строготипизированное — очень тяжелая задача, сложность которой, зависит уже не от нас.
Есть еще много пунктов, почему мы имплементим поддержку языков сами. Да, расхождения случаются, но мы стараемся их фиксить по мере поступления баг-репортов.