Сообщение Re[2]: Resharper дико тормозит на файлах с LanguageExt от 15.12.2016 19:51
Изменено 15.12.2016 20:17 Слава
Здравствуйте, ollka, Вы писали:
O>Что мы можем сделать — это поработать над отзывчивостью. Тут есть что улучшать и куда копать. Но по сути разогнать алгоритм Overload resolution здесь не слишком реалистично.
Благодарю вас за ответ.
У меня есть пожелание — если файл не менялся, то не анализировать его еще раз. А если его закрыли — так тем более не анализировать, или уводить анализ в фон. Какое-то кэширование использовать, что-ли... или быть может некий монитор, показывающий "а что сейчас делает Решарпер?" с возможностью указать некоему процессу "умри" или же понизить приоритет конкретно этого действия или класса действий.
Если изменений в файле нет, или изменение не несёт смысла — к одному пробелу второй добавили, один перенос строки двумя заменили, то что должно заново анализироваться так упорно, что даже прокрутка не работает?
В моём проекте в итоге решили бороться с тормозами следующим образом:
(создали файл с реально используемыми элементами)
(и стали везде использовать его, а не весь поперёк себя широкий LanguageExt)
Из этого же ясно, что сами создатели LanguageExt виноваты в тормозах — а зачем они засунули в один namespace вообще всё, что у них есть? Функциональщики такие функциональщики... avoid success at all costs.
O>Что мы можем сделать — это поработать над отзывчивостью. Тут есть что улучшать и куда копать. Но по сути разогнать алгоритм Overload resolution здесь не слишком реалистично.
Благодарю вас за ответ.
У меня есть пожелание — если файл не менялся, то не анализировать его еще раз. А если его закрыли — так тем более не анализировать, или уводить анализ в фон. Какое-то кэширование использовать, что-ли... или быть может некий монитор, показывающий "а что сейчас делает Решарпер?" с возможностью указать некоему процессу "умри" или же понизить приоритет конкретно этого действия или класса действий.
Если изменений в файле нет, или изменение не несёт смысла — к одному пробелу второй добавили, один перенос строки двумя заменили, то что должно заново анализироваться так упорно, что даже прокрутка не работает?
В моём проекте в итоге решили бороться с тормозами следующим образом:
(создали файл с реально используемыми элементами)
using LanguageExt;
namespace Infrastructure.Extensions
{
public static class LanguageExtExtensions
{
public static Ret match<L, R, Ret>(Either<L, R> either, Func<R, Ret> Right, Func<L, Ret> Left)
=> Prelude.match(either, Right, Left);
public static Unit match<L, R>(Either<L, R> either, Action<R> Right, Action<L> Left)
=> Prelude.match(either, Right, Left);
public static R match<T, R>(Option<T> option, Func<T, R> Some, Func<R> None)
=> Prelude.match(option, Some, None);
public static Either<L, R> Right<L, R>(R value)
=> Prelude.Right<L, R>(value);
public static Either<L, R> Right<L, R>(R? value) where R : struct
=> Prelude.Right<L, R>(value);
public static Either<L, R> Left<L, R>(L value)
=> Prelude.Left<L, R>(value);
public static Either<L, R> Left<L, R>(L? value) where L : struct
=> Prelude.Left<L, R>(value);
public static Option<T> Some<T>(T value)
=> Prelude.Some(value);
public static Option<T> Some<T>(T? value) where T : struct
=> Prelude.Some(value);
}
}(и стали везде использовать его, а не весь поперёк себя широкий LanguageExt)
using static Infrastructure.Extensions.LanguageExtExtensions;Из этого же ясно, что сами создатели LanguageExt виноваты в тормозах — а зачем они засунули в один namespace вообще всё, что у них есть? Функциональщики такие функциональщики... avoid success at all costs.
| Пример LINQ, приводившего R# в ступор | |
| |
Re[2]: Resharper дико тормозит на файлах с LanguageExt
Здравствуйте, ollka, Вы писали:
O>Что мы можем сделать — это поработать над отзывчивостью. Тут есть что улучшать и куда копать. Но по сути разогнать алгоритм Overload resolution здесь не слишком реалистично.
Благодарю вас за ответ.
У меня есть пожелание — если файл не менялся, то не анализировать его еще раз. А если его закрыли — так тем более не анализировать, или уводить анализ в фон. Какое-то кэширование использовать, что-ли... или быть может некий монитор, показывающий "а что сейчас делает Решарпер?" с возможностью указать некоему процессу "умри" или же понизить приоритет конкретно этого действия или класса действий.
Если изменений в файле нет, или изменение не несёт смысла — к одному пробелу второй добавили, один перенос строки двумя заменили, то что должно заново анализироваться так упорно, что даже прокрутка не работает?
В моём проекте в итоге решили бороться с тормозами следующим образом:
(создали файл с реально используемыми элементами)
(и стали везде использовать его, а не весь поперёк себя широкий LanguageExt)
Из этого же ясно, что сами создатели LanguageExt виноваты в тормозах — а зачем они засунули в один namespace вообще всё, что у них есть? Функциональщики такие функциональщики... avoid success at all costs.
O>Что мы можем сделать — это поработать над отзывчивостью. Тут есть что улучшать и куда копать. Но по сути разогнать алгоритм Overload resolution здесь не слишком реалистично.
Благодарю вас за ответ.
У меня есть пожелание — если файл не менялся, то не анализировать его еще раз. А если его закрыли — так тем более не анализировать, или уводить анализ в фон. Какое-то кэширование использовать, что-ли... или быть может некий монитор, показывающий "а что сейчас делает Решарпер?" с возможностью указать некоему процессу "умри" или же понизить приоритет конкретно этого действия или класса действий.
Если изменений в файле нет, или изменение не несёт смысла — к одному пробелу второй добавили, один перенос строки двумя заменили, то что должно заново анализироваться так упорно, что даже прокрутка не работает?
В моём проекте в итоге решили бороться с тормозами следующим образом:
(создали файл с реально используемыми элементами)
using LanguageExt;
namespace Infrastructure.Extensions
{
public static class LanguageExtExtensions
{
public static Ret match<L, R, Ret>(Either<L, R> either, Func<R, Ret> Right, Func<L, Ret> Left)
=> Prelude.match(either, Right, Left);
public static Unit match<L, R>(Either<L, R> either, Action<R> Right, Action<L> Left)
=> Prelude.match(either, Right, Left);
public static R match<T, R>(Option<T> option, Func<T, R> Some, Func<R> None)
=> Prelude.match(option, Some, None);
public static Either<L, R> Right<L, R>(R value)
=> Prelude.Right<L, R>(value);
public static Either<L, R> Right<L, R>(R? value) where R : struct
=> Prelude.Right<L, R>(value);
public static Either<L, R> Left<L, R>(L value)
=> Prelude.Left<L, R>(value);
public static Either<L, R> Left<L, R>(L? value) where L : struct
=> Prelude.Left<L, R>(value);
public static Option<T> Some<T>(T value)
=> Prelude.Some(value);
public static Option<T> Some<T>(T? value) where T : struct
=> Prelude.Some(value);
}
}(и стали везде использовать его, а не весь поперёк себя широкий LanguageExt)
using static Infrastructure.Extensions.LanguageExtExtensions;Из этого же ясно, что сами создатели LanguageExt виноваты в тормозах — а зачем они засунули в один namespace вообще всё, что у них есть? Функциональщики такие функциональщики... avoid success at all costs.
| Пример LINQ, приводившего R# в ступор | |||||||
| |||||||