Здравствуйте, Serginio1, Вы писали:
I>>Я не сильно понимаю эти результаты. Что такое удавы и какой код получил 3 удава? Самый быстрый это 3 или 5 ? S>Ну посмотри статью. Там все написано и расписано.
Я же сказал — мне непонятно. Выглядит, как будто магия
То есть, x[0] оказывается медленее чем x.First() который унутре все равно вызовет x[0]
Подозреваю, некорректный тесты.
I>>Я вижу, что здесь непойми что и не ясно, зачем вообще выделять память. Зачем делать add() если можно просто вызвать соответствующую функцию? I>>Память нужно выделять в том случае, если у нас есть многочисленные повторные проходы по источнику.
S> В том, что нужно получать итератор. А здесь как раз идет сравнение с итератора и через прямое вычисление без итераторов. S>Так или иначе идет вызов MoveNext на стороне итератора идут 10 вызовов кстати через индекс так как передан массив.
Непонятно — x[0] стал медленее того же x[0] завернутого в функцию с телом yield x[0].
Тебе не кажется это странным?
S>Но нужны коллекции для заиси в базу, отображения итд
I>>То ты сэкономишь кучу памяти, но при этом работа с источником окажется примерно в 1000 раз медленнее. I>>И для оптимизации используется кеширование коллекции.
S>В реалии Отборов может быть великое множество. Памяти не хватит кэшировать.
В реальности оптимизации подбираем под соответствующие узкие места, а не абы как.
S>Мало того данные имеют свойство меняться
S>3 попугая для S>[cs] S>public int Iterative() S> { S> var counter = 0; S> foreach (var item in items) S> { S> if (item % 10 == 0) S> counter += item; S> }
Если попугаи это секунды, то следовательно самый быстрый код это простой проход по массиву, как я тебе и говорил.
А раз самый медленный это 5.08, то это почти в два раза хуже.
Ты точно думаешь, что две секунды это почти так же хорошо, как и одна?
S>Но когда нам нужны коллекции заполнение List оказывается значительно дороже.
А кто тебя просит их создавать?
Где здесь коллекция:
let state = initial();
let i = 0;
while(true) {
i++;
state = state.next(i);
if(isGoodEnough(state, i)) {
return {state, i};
}
}
Re[42]: Есть ли подобие LINQ на других языках/платформах?
Здравствуйте, Serginio1, Вы писали:
I>>Я могу написать другой тест, который провалит замеры против массива во сколько угодно раз.
I>>Речь то не идет о том, плох linq или хорош, а о том, когда и где хорошо справляется, а когда и где есть вещи получше.
I>>Я уверен, ты не понимаешь фразу выше. Ну не понимаешь и всё. Особенность у тебя такая. Попроси может кого, что бы объяснили, что это значит с т.з. русского языка. S> Вот напиши и покажи. S>И обоснуй минус!
Все что надо, уже сделано. ты сам показал тесты, где прямая итерация оказывается быстрее косвенной через yield
Re[43]: Есть ли подобие LINQ на других языках/платформах?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Serginio1, Вы писали:
I>>>Я могу написать другой тест, который провалит замеры против массива во сколько угодно раз.
I>>>Речь то не идет о том, плох linq или хорош, а о том, когда и где хорошо справляется, а когда и где есть вещи получше.
I>>>Я уверен, ты не понимаешь фразу выше. Ну не понимаешь и всё. Особенность у тебя такая. Попроси может кого, что бы объяснили, что это значит с т.з. русского языка. S>> Вот напиши и покажи. S>>И обоснуй минус!
I>Все что надо, уже сделано. ты сам показал тесты, где прямая итерация оказывается быстрее косвенной через yield
Все последнее сообщение. Ты так и не понял смысл Linq для коллекций.
1. Суть прежде всего в читаемости кода!
2. Быть достаточно производительныим и !!! ленивым и жрали по минимуму памяти
то есть вычиления идут с права на лево, без создания итераторов на List (при этом вычисления пойдут с лева направо, так как для получения итератора на уровне Lis
нужно вызвать все MoveNext у родительского итератора)
3. Можно оптимизировать запросы если все находятся в одном месте по типу Linq Rewrite
используя тот же Source генератор. По сути это аналог IQueryable,но на этапе компиляции и можно в нем отлаживать код!!
4. Там где нужно динамически создавать цепочки запросов. Тут просто вручную невозможно оптимизировать. Слишком много вариантов.
Понятно, что там где скорость нужна и нужно экономить секунды или десятки секунд ручная оптимизация нужна.
Но там где тратятся миллисекунды Linq прекрасно работает даже если это будет в 4 раза дольше чем все в ручную, потому что например запись в БД,
отображение данных или ответ на Htth запрос с последующей десериализацие данных намного дольше чем работа итераторов.
А вот читаемость кода значительно важнее. Особенно кода количество кода измеряется мегабайтами. Скорость кодирования и разбираться с чужим своим кодом намного важнее.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Serginio1, Вы писали:
S>>Все это словоблудие. Вот реальные замеры производительности S>>http://rsdn.org/forum/flame.comp/7995827.1
I>Я могу написать другой тест, который провалит замеры против массива во сколько угодно раз.
Суть такая там максимально замер через обход массива и с инлайновым вычислением значения.
Против получения итератора и на нем вычислить значение.
Тест показывает какие затраты мы получаем через yield и через создание итератора через массив
С максимально быстрым получением результата. И вывод из этого теста, то что yield проигрывает максимум в 4 раза
(на косвенность по MoveNext и Current как раз в 2 раза на каждый).
И то что затраты на выделение памяти в итоге лишние и получаются больше чем на MoveNext и Current
Делай хоть какие тесты суть от этого не изменится
Я тебе про этот тест давно ссылку давал https://mattwarren.org/2016/09/29/Optimising-LINQ/
Но ты просто проигнорировал, даже после того как я еще раз дал ты начал спрашивать, а что за попугаи. Это абсолютное пренебрежение.
I>Речь то не идет о том, плох linq или хорош, а о том, когда и где хорошо справляется, а когда и где есть вещи получше. I>Я уверен, ты не понимаешь фразу выше. Ну не понимаешь и всё. Особенность у тебя такая. Попроси может кого, что бы объяснили, что это значит с т.з. русского языка.
Нет речь идет о преимуществах вычислений с права на лево. За что ты мне минус и поставил!
А все остальное болтовня
и солнце б утром не вставало, когда бы не было меня
Re[41]: Есть ли подобие LINQ на других языках/платформах?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Serginio1, Вы писали:
I>>>Я не сильно понимаю эти результаты. Что такое удавы и какой код получил 3 удава? Самый быстрый это 3 или 5 ? S>>Ну посмотри статью. Там все написано и расписано.
I>Я же сказал — мне непонятно. Выглядит, как будто магия I>То есть, x[0] оказывается медленее чем x.First() который унутре все равно вызовет x[0]
Нет вывод в том, что ты должен вернуть енумератор на котором вызовется First().
А вот создать енумератор можно по разному через List или yield. В итоге yield выигрывает за счет отсутствия затрат на выделение и запись в память.
То есть вычисления с права на лево выгоднее за счет отсутствия лишних затрат на выделение памяти.
А это легко организуется через yield
I>То есть, если ты сотню раз будешь использовать источник такого вида I>
I>while(true) {
I> yield i++;
I>}
I>
I>То ты сэкономишь кучу памяти, но при этом работа с источником окажется примерно в 1000 раз медленнее. I>И для оптимизации используется кеширование коллекции.
Специально сделал тест
class Program
{
static long InlineCalk()
{
long result = 0;
for (int i = 0; i < int.MaxValue/2; i++)
result += i;
return result;
}
static IEnumerable<int> GetEnumerable()
{
for (int i = 0; i < int.MaxValue/2; i++)
yield return i;
}
static long YieldCalk()
{
long result = 0;
foreach (int i in GetEnumerable())
result += i;
return result;
}
static void Main(string[] args)
{
var r = DateTime.Now;
var result=InlineCalk();
var res = (DateTime.Now - r).TotalMilliseconds;
Console.WriteLine(res);
Console.WriteLine(result);
r = DateTime.Now;
result=YieldCalk();
var res2 = (DateTime.Now - r).TotalMilliseconds;
Console.WriteLine(result);
Console.WriteLine(res2);
Console.WriteLine($"отношение yield к inline {res2 / res}");
Console.ReadLine();
}
}
727,6487
576460750692810753
576460750692810753
6389,199
отношение yield к inline 8,780609379223794
То есть ты ошибся как минимум раз в 100! Ну какая хрен разница подумаешь! Главное медленнее. Но цифрами бросаться все же не стоит.
И это на result += i; Если будут функции с поиском в хэштаблице и ли функции работы со строками,
а учитывая, что в реалии нужно обращаться к данным, которые могут находиться вне кэша памяти, то это отношение будет стремиться к 1!!
То есть ни о каких 1000 и близко нет, но вот если тебе понадобится коллекция то ты на памяти больше потеряешь.
А что мне кэшировать если
1. Данные меняются
2. Мне нужно один раз получить такой итератор с такими условиями.
Кстати в .Net появился ref return
public class MyIterator
{
int Result = 0;
int state = 0;
public ref int ReturnResult()
{
return ref Result;
}
public bool MoveNext()
{
switch (this.state)
{
case 0:
Result = 0;
state = 1;
return true;
case 1:
Result++;
if (Result == int.MaxValue / 2)
{
state = 3;
return false;
}
return true;
default:
return false;
}
}
}
И получать Current по ссылке
static long RefResult()
{
long result = 0;
var iter = new MyIterator();
ref int res = ref iter.ReturnResult();
while (iter.MoveNext())
result += res;
return result;
}
и вызов
r = DateTime.Now;
result = RefResult();
var res3 = (DateTime.Now - r).TotalMilliseconds;
Console.WriteLine(result);
Console.WriteLine(res3);
Console.WriteLine($"отношение RefResult к inline {res3 / res}");
То получим
576460750692810753
3235,4582
отношение RefResult к inline 4,327135105321729
То есть ошибся всего в 250 раз!!
Ну в MS считают, что это не принципиально
Но к сожалению такая конструкция
static IEnumerable<int> GetEnumerable2()
{
var iter = new MyIterator();
ref int res = ref iter.ReturnResult();
while (iter.MoveNext())
yield return res;
}
Ругается на ref int res = ref iter.ReturnResult();
Итераторы не могут иметь переменные по ссылке
Но если заменить MoveNext
public bool MoveNext2(ref int result)
{
switch (this.state)
{
case 0:
Result = 0;
state = 1;
return true;
case 1:
Result++;
if (Result == int.MaxValue / 2)
{
state = 3;
return false;
}
result = Result;
return true;
default:
return false;
}
}
И вызов
static long RefResult2()
{
long result = 0;
var iter = new MyIterator();
int res = 0;
while (iter.MoveNext2(ref res))
result += res;
return result;
}
То получим
576460750692810753
3420,4316
отношение RefResult к inline 4,805504333751022
Можно безболезненно и сейчас увеличит производительность, если все итераторы будут наследоваться от одного класса
public class MyIterator<T>
{
public T Result = default(t);
И вызов
static long RefResult3()
{
long result = 0;
var iter = new MyIterator();
int res = 0;
while (iter.MoveNext())
result += iter.Result;
return result;
}
Тогда отношение будет всего 3,530814317127427
То есть ошибся ты всего в 300 раз.
Вот и верь тебе!!
Ну не нужно это MS
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>отношение yield к inline 8,780609379223794
S>То есть ты ошибся как минимум раз в 100! Ну какая хрен разница подумаешь! Главное медленнее. Но цифрами бросаться все же не стоит.
Во первых, ты выяснил, что yield cущественно медленнее
Во вторых, 100 раз следует не из такого теста. Нужен алгоритм посложнее, когда, например, ты пробегаешься много раз по одному источнику или, например, часто вызываешь нечто навроде x.First().
В таком случаяъ ты можешь получить какое угодно замедление.
>а учитывая, что в реалии нужно обращаться к данным, которые могут находиться вне кэша памяти, то это отношение будет стремиться к 1!!
Обычно — да. Но не всегда. Если весь твой код плотно завязан на linq, и это, скажем, in-memory процессинг, то ты всего то работаешь в разы медленнее Это не проблема, пока не станет узким местом. Вопрос в том, как это узкое место устранять.
Дальше ты ничего существенного не привел. Извини, скипнул.
Собственно, в своё время я соптимизировал довольно тяжелый процессинг в разных операциях от 10 до 10000 раз, в одном месте убирая итераторы и linq, в другом месте добавляя их. Где то вводил кеширование, где то заменял на предопределенные значения.
Где то переходил на IList<T>, где то на IEnumerable<T>, где то были массивы, а где то коллекции типа deque, где то избавлялся от массивов, где то переводил всё именно на них.
Например, репортинг я весь перевел на IEnumerable<Е> и Linq. А вот в рендеринге вычистил даже намёки на IEnumerable.
Скажем, итерироваться по deque по индексу можно, но эта идея сильно глупая, т.е. deque оптимизирована под быстрое добавление-удаление с обоих сторон. Тут IEnumerable<T> будет в самый раз, а доступ по индексу я просто убрал.
С другой стороны, в часто используемых коллекциях я вообще все перевел на массивы и получил огромный бенефит.
Re[42]: Есть ли подобие LINQ на других языках/платформах?
Здравствуйте, Serginio1, Вы писали:
I>>Я же сказал — мне непонятно. Выглядит, как будто магия I>>То есть, x[0] оказывается медленее чем x.First() который унутре все равно вызовет x[0] S>Нет вывод в том, что ты должен вернуть енумератор на котором вызовется First().
А зачем мне вообще создавать энумератор ради взятия первого элемента?
Re[42]: Есть ли подобие LINQ на других языках/платформах?
Здравствуйте, Serginio1, Вы писали:
I>>Я могу написать другой тест, который провалит замеры против массива во сколько угодно раз. S>Суть такая там максимально замер через обход массива и с инлайновым вычислением значения.
Не максимальный, а просто частный случай.
S>Делай хоть какие тесты суть от этого не изменится
Наоборот. Вот тебе тест:
while(true) {
yield i++;
}
Попробуй код такого вида вызывать в линейном алгоритме с рандомным доступом, типа ElementAt(i).
Ты, внезапно, получишь квадратичное ухудшение. То есть, тысяча-другая итераций будут работать всего как миллион
S>Я тебе про этот тест давно ссылку давал https://mattwarren.org/2016/09/29/Optimising-LINQ/ S>Но ты просто проигнорировал, даже после того как я еще раз дал ты начал спрашивать, а что за попугаи. Это абсолютное пренебрежение.
В этой статье только частные случаи, ничего нового. Вопрос про попугаи абсолютно легальный. Просто ты не хочешь уточнять сказаное тобой же.
Вообще, ты ведь только что доказал, что 8.7 кратная разница возможна. На самом деле возможно и больше. Нужно это учитывать. Пример выше.
Re[44]: Есть ли подобие LINQ на других языках/платформах?
Здравствуйте, Serginio1, Вы писали:
I>>Все что надо, уже сделано. ты сам показал тесты, где прямая итерация оказывается быстрее косвенной через yield S>Все последнее сообщение. Ты так и не понял смысл Linq для коллекций. S>1. Суть прежде всего в читаемости кода!
Что мне с читаемости, когда мне надо обеспечить ускорение от 10 до 10000 раз ?
S>2. Быть достаточно производительныим и !!! ленивым и жрали по минимуму памяти
Минимум памяти часто бывает максимум по процессору.
S>то есть вычиления идут с права на лево, без создания итераторов на List (при этом вычисления пойдут с лева направо, так как для получения итератора на уровне Lis S>нужно вызвать все MoveNext у родительского итератора)
А небо голубое.
S>3. Можно оптимизировать запросы если все находятся в одном месте по типу Linq Rewrite
Можно. Но есть и другие варианты.
S> Понятно, что там где скорость нужна и нужно экономить секунды или десятки секунд ручная оптимизация нужна.
О как! А если не секунды, а часы и дни а задержки стоят больших денег? Предложишь переписать всё на С++?
S>Но там где тратятся миллисекунды Linq прекрасно работает даже если это будет в 4 раза дольше чем все в ручную, потому что например запись в БД, S>отображение данных или ответ на Htth запрос с последующей десериализацие данных намного дольше чем работа итераторов.
Это что, посреди числодробилки я полезу в бд или по хттп на сервер? Идея весьма оригинальная, надо бы обкатать.
S>А вот читаемость кода значительно важнее. Особенно кода количество кода измеряется мегабайтами. Скорость кодирования и разбираться с чужим своим кодом намного важнее.
Важнее чем что? Никому это не интересно, если цель недостижима.
Разве я предлагаю отказаться от Linq и перейти на массивы?
Re[41]: Есть ли подобие LINQ на других языках/платформах?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Serginio1, Вы писали:
S>>отношение yield к inline 8,780609379223794
S>>То есть ты ошибся как минимум раз в 100! Ну какая хрен разница подумаешь! Главное медленнее. Но цифрами бросаться все же не стоит.
I>Во первых, ты выяснил, что yield cущественно медленнее
Ну не в 1000 раз!! Та затраты на MoveNext и Current есть. Но это порядка 3 секунд на миллиард!!
Реальные коллекции не достигают и миллиона. А это миллисекунды. I>Во вторых, 100 раз следует не из такого теста. Нужен алгоритм посложнее, когда, например, ты пробегаешься много раз по одному источнику или, например, часто вызываешь нечто навроде x.First(). I>В таком случаяъ ты можешь получить какое угодно замедление.
В честь чего? Твои теории пока никак не подтверждены практикой.
>>а учитывая, что в реалии нужно обращаться к данным, которые могут находиться вне кэша памяти, то это отношение будет стремиться к 1!!
I>Обычно — да. Но не всегда. Если весь твой код плотно завязан на linq, и это, скажем, in-memory процессинг, то ты всего то работаешь в разы медленнее Это не проблема, пока не станет узким местом. Вопрос в том, как это узкое место устранять.
Это станет узким местом при данных порядка миллиарда!! Все остальное это миллисекунды Которые и ловить не стоит. I>Дальше ты ничего существенного не привел. Извини, скипнул.
I>Собственно, в своё время я соптимизировал довольно тяжелый процессинг в разных операциях от 10 до 10000 раз, в одном месте убирая итераторы и linq, в другом месте добавляя их. Где то вводил кеширование, где то заменял на предопределенные значения. I>Где то переходил на IList<T>, где то на IEnumerable<T>, где то были массивы, а где то коллекции типа deque, где то избавлялся от массивов, где то переводил всё именно на них.
I>Например, репортинг я весь перевел на IEnumerable<Е> и Linq. А вот в рендеринге вычистил даже намёки на IEnumerable.
I>Скажем, итерироваться по deque по индексу можно, но эта идея сильно глупая, т.е. deque оптимизирована под быстрое добавление-удаление с обоих сторон. Тут IEnumerable<T> будет в самый раз, а доступ по индексу я просто убрал.
I>С другой стороны, в часто используемых коллекциях я вообще все перевел на массивы и получил огромный бенефит.
Огромный ты не получишь. Максимум в 10 раз но и объемы у тебя должны быть огроменными. Ну и можно всегда использовать Linq Rewrite
и солнце б утром не вставало, когда бы не было меня
Re[43]: Есть ли подобие LINQ на других языках/платформах?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Serginio1, Вы писали:
I>>>Я же сказал — мне непонятно. Выглядит, как будто магия I>>>То есть, x[0] оказывается медленее чем x.First() который унутре все равно вызовет x[0] S>>Нет вывод в том, что ты должен вернуть енумератор на котором вызовется First().
I>А зачем мне вообще создавать энумератор ради взятия первого элемента?
Там длинная цепочка Where, Select join итд может быть
и солнце б утром не вставало, когда бы не было меня
Re[43]: Есть ли подобие LINQ на других языках/платформах?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Serginio1, Вы писали:
I>>>Я могу написать другой тест, который провалит замеры против массива во сколько угодно раз. S>>Суть такая там максимально замер через обход массива и с инлайновым вычислением значения.
I>Не максимальный, а просто частный случай.
S>>Делай хоть какие тесты суть от этого не изменится
I>Наоборот. Вот тебе тест: I>
I>while(true) {
I> yield i++;
I>}
I>
I>Попробуй код такого вида вызывать в линейном алгоритме с рандомным доступом, типа ElementAt(i). I>Ты, внезапно, получишь квадратичное ухудшение. То есть, тысяча-другая итераций будут работать всего как миллион
Ну в таких случаях делают ToList() и работают с индексами.
Но до этого нужно наложить соединения, фильтры итд
S>>Я тебе про этот тест давно ссылку давал https://mattwarren.org/2016/09/29/Optimising-LINQ/ S>>Но ты просто проигнорировал, даже после того как я еще раз дал ты начал спрашивать, а что за попугаи. Это абсолютное пренебрежение.
I>В этой статье только частные случаи, ничего нового. Вопрос про попугаи абсолютно легальный. Просто ты не хочешь уточнять сказаное тобой же. I>Вообще, ты ведь только что доказал, что 8.7 кратная разница возможна. На самом деле возможно и больше. Нужно это учитывать. Пример выше.
Это как общий случай. Смысл его, что при вычислении слева направо расходуется лишняя память и еще к тому же и существенное замедление.
и солнце б утром не вставало, когда бы не было меня
Re[45]: Есть ли подобие LINQ на других языках/платформах?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Serginio1, Вы писали:
I>>>Все что надо, уже сделано. ты сам показал тесты, где прямая итерация оказывается быстрее косвенной через yield S>>Все последнее сообщение. Ты так и не понял смысл Linq для коллекций. S>>1. Суть прежде всего в читаемости кода!
I>Что мне с читаемости, когда мне надо обеспечить ускорение от 10 до 10000 раз ?
Ну как показал тест максимум в 9 раз ты получишь ускорение. Ни о каких 10000 нет и разговора S>>2. Быть достаточно производительныим и !!! ленивым и жрали по минимуму памяти
I>О как! А если не секунды, а часы и дни а задержки стоят больших денег? Предложишь переписать всё на С++?
S>>Но там где тратятся миллисекунды Linq прекрасно работает даже если это будет в 4 раза дольше чем все в ручную, потому что например запись в БД, S>>отображение данных или ответ на Htth запрос с последующей десериализацие данных намного дольше чем работа итераторов.
I>Это что, посреди числодробилки я полезу в бд или по хттп на сервер? Идея весьма оригинальная, надо бы обкатать.
В 99% использования Linq это не числодробилки. А именно запись в БД,хттп, вывод для отображения итд S>>А вот читаемость кода значительно важнее. Особенно кода количество кода измеряется мегабайтами. Скорость кодирования и разбираться с чужим своим кодом намного важнее.
I>Важнее чем что? Никому это не интересно, если цель недостижима. I>Разве я предлагаю отказаться от Linq и перейти на массивы?
Минус то ты поставил!!
И что смешного в http://rsdn.org/forum/flame.comp/7996919.1
Я показал, что ты заблуждаешься. Не нравится сделай свой тест и покажи результаты.
Пока у тебя обычное словоблудие.
А я потратил между прочим кучу времени,и за это получаю ухмылки!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Ну как показал тест максимум в 9 раз ты получишь ускорение. Ни о каких 10000 нет и разговора
Зависит от алгоритма, что очевидно. Сколько итераторов ты навернешь, столько и будет оверхеда. Сколько проходов по источнику, столько и оверхеда.
Неужели непонятно?
Если это узкое место и от него можно избавиться, то зачем держаться за линк?
I>>Это что, посреди числодробилки я полезу в бд или по хттп на сервер? Идея весьма оригинальная, надо бы обкатать. S> В 99% использования Linq это не числодробилки. А именно запись в БД,хттп, вывод для отображения итд
Да ладно. Эдакая чудо-технология, которая только по назначению и применяется. Ага. Чудо — если девелопер пишет на линке, то он пишет правильно и применяет его правильно
S>>>А вот читаемость кода значительно важнее. Особенно кода количество кода измеряется мегабайтами. Скорость кодирования и разбираться с чужим своим кодом намного важнее.
I>>Разве я предлагаю отказаться от Linq и перейти на массивы? S> Минус то ты поставил!!
Слова про 10, 100, 1000 раз это все про конкретные кейсы.
Ты замеряешь другой кейс, делаешь вывод что все не так. Вот это и смешно.
S>Я показал, что ты заблуждаешься. Не нравится сделай свой тест и покажи результаты.
Так уже. Твоих вполне достаточно — тривиальный кейс дает замедление в 8 раз.
Думаешь, более сложный будет быстрее работать?
Re[44]: Есть ли подобие LINQ на других языках/платформах?
Здравствуйте, Serginio1, Вы писали:
I>>Ты, внезапно, получишь квадратичное ухудшение. То есть, тысяча-другая итераций будут работать всего как миллион S>Ну в таких случаях делают ToList() и работают с индексами.
Браво! О чем я тебе и говорю.
S>Но до этого нужно наложить соединения, фильтры итд
Это смотря как накладывать. Десяток соединений да фильтров если в лоб, то дадут тебе проседание если не 8.7*10 то сравнимое
Т.е. чем длиннее цепочка, тем больше издержки. Это окупается в большинстве сценариев, но далеко не во всех.
I>>В этой статье только частные случаи, ничего нового. Вопрос про попугаи абсолютно легальный. Просто ты не хочешь уточнять сказаное тобой же. I>>Вообще, ты ведь только что доказал, что 8.7 кратная разница возможна. На самом деле возможно и больше. Нужно это учитывать. Пример выше. S> Это как общий случай. Смысл его, что при вычислении слева направо расходуется лишняя память и еще к тому же и существенное замедление.
Ты сам то понял, что сказал? Именно — лишняя память и существенное замедление. Потому ускориться можно сменив алгоритм, т.е. отказаться от линка.
Re[44]: Есть ли подобие LINQ на других языках/платформах?
Здравствуйте, Serginio1, Вы писали:
I>>>>То есть, x[0] оказывается медленее чем x.First() который унутре все равно вызовет x[0] S>>>Нет вывод в том, что ты должен вернуть енумератор на котором вызовется First().
I>>А зачем мне вообще создавать энумератор ради взятия первого элемента? S>Там длинная цепочка Where, Select join итд может быть
Разумеется, если у тебя все завязано на линк, то иначе никак.
Если цель — убрать узкое место, то можно просто напросто другой алгоритм взять или даже вычислительную модель поменять.
А у тебя, похоже, нужно только за линк держаться, не дай бог отступить ради оптимизации
Re[42]: Есть ли подобие LINQ на других языках/платформах?
Здравствуйте, Serginio1, Вы писали:
S>Ну не в 1000 раз!! Та затраты на MoveNext и Current есть. Но это порядка 3 секунд на миллиард!!
Если разница 8 раз, очевидно, что вычисления в один час будут идти 8 часов.
S>Реальные коллекции не достигают и миллиона. А это миллисекунды.
Коллекции — нет, а вот итерации — да.
I>>В таком случаяъ ты можешь получить какое угодно замедление. S> В честь чего? Твои теории пока никак не подтверждены практикой.
Высокая стоимость. Потому нужно при возможности экспозить IList, тогда стандартный First обратится по индексу.
I>>Обычно — да. Но не всегда. Если весь твой код плотно завязан на linq, и это, скажем, in-memory процессинг, то ты всего то работаешь в разы медленнее Это не проблема, пока не станет узким местом. Вопрос в том, как это узкое место устранять. S> Это станет узким местом при данных порядка миллиарда!! Все остальное это миллисекунды Которые и ловить не стоит.
Одна из моих оптимизаций сократила процессинг с 6 часов, до 6 минут. Небольшое кеширование добавил.
Всего на оптимизации потратил год с небольшой командой.
Масштабы понятны?
I>>Например, репортинг я весь перевел на IEnumerable<Е> и Linq. А вот в рендеринге вычистил даже намёки на IEnumerable. I>>С другой стороны, в часто используемых коллекциях я вообще все перевел на массивы и получил огромный бенефит. S>Огромный ты не получишь. Максимум в 10 раз но и объемы у тебя должны быть огроменными. Ну и можно всегда использовать Linq Rewrite
Я уже озвучил бенефиты. От 10 до 10000 раз. Это после года работы над проектом.
Объемы огроменные. Не bigdata, но много всякого было.
Re[47]: Есть ли подобие LINQ на других языках/платформах?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Serginio1, Вы писали:
S>>Ну как показал тест максимум в 9 раз ты получишь ускорение. Ни о каких 10000 нет и разговора
I>Зависит от алгоритма, что очевидно. Сколько итераторов ты навернешь, столько и будет оверхеда. Сколько проходов по источнику, столько и оверхеда. I>Неужели непонятно?
Понятно. Но например Where объединять, а Select будут отжирать намного больше че MoveNext и Current I>Если это узкое место и от него можно избавиться, то зачем держаться за линк?
Нахрена мне экотнмить десятые миллисекунды, если читаемость линка намного выше?
I>>>Это что, посреди числодробилки я полезу в бд или по хттп на сервер? Идея весьма оригинальная, надо бы обкатать. S>> В 99% использования Linq это не числодробилки. А именно запись в БД,хттп, вывод для отображения итд
I>Да ладно. Эдакая чудо-технология, которая только по назначению и применяется. Ага. Чудо — если девелопер пишет на линке, то он пишет правильно и применяет его правильно
Я на самом деле редко применяю линк, но там где это возможно использую с удовольствием. Производительность ну никак не проседает, ибо доля затрат мизерная.
S>>>>А вот читаемость кода значительно важнее. Особенно кода количество кода измеряется мегабайтами. Скорость кодирования и разбираться с чужим своим кодом намного важнее.
I>>>Разве я предлагаю отказаться от Linq и перейти на массивы? S>> Минус то ты поставил!!
I>А разве минус говорит о том, что надо отказываться?
Т S>> И что смешного в http://rsdn.org/forum/flame.comp/7996919.1
I>Слова про 10, 100, 1000 раз это все про конкретные кейсы. I>Ты замеряешь другой кейс, делаешь вывод что все не так. Вот это и смешно.
Я замеряю отношение yield i++ c i++ ты же говорил о 1000. Разве нет?
S>>Я показал, что ты заблуждаешься. Не нравится сделай свой тест и покажи результаты.
I>Так уже. Твоих вполне достаточно — тривиальный кейс дает замедление в 8 раз. I>Думаешь, более сложный будет быстрее работать?
Нет я показал как легко сделать и 3.5. Но никому это не надо. В реальных условиях это миллисекунды
и солнце б утром не вставало, когда бы не было меня
Re[45]: Есть ли подобие LINQ на других языках/платформах?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Serginio1, Вы писали:
I>>>Ты, внезапно, получишь квадратичное ухудшение. То есть, тысяча-другая итераций будут работать всего как миллион S>>Ну в таких случаях делают ToList() и работают с индексами.
I>Браво! О чем я тебе и говорю.
Да но при этом я могу и не делат ToList или ToDictionary IEnumerable более универсален. S>>Но до этого нужно наложить соединения, фильтры итд
I>Это смотря как накладывать. Десяток соединений да фильтров если в лоб, то дадут тебе проседание если не 8.7*10 то сравнимое I>Т.е. чем длиннее цепочка, тем больше издержки. Это окупается в большинстве сценариев, но далеко не во всех.
Уще раз Where можно объединять. Но ты не забывай и про другие накладные расходы. Я просто привел максимально производительный
res+=i; никаких ифов вычислений, которые будут на равне или даже дольше MoveNext Current. Опять ошибаешься
I>>>В этой статье только частные случаи, ничего нового. Вопрос про попугаи абсолютно легальный. Просто ты не хочешь уточнять сказаное тобой же. I>>>Вообще, ты ведь только что доказал, что 8.7 кратная разница возможна. На самом деле возможно и больше. Нужно это учитывать. Пример выше. S>> Это как общий случай. Смысл его, что при вычислении слева направо расходуется лишняя память и еще к тому же и существенное замедление.
I>Ты сам то понял, что сказал? Именно — лишняя память и существенное замедление. Потому ускориться можно сменив алгоритм, т.е. отказаться от линка.
Это все словоблудие. Давай реальные данные. А именно коллекции. И реальные данные до миллиона. И сколько это миллисекунд.
Ты же что то там мерял?
По твоему нужно вообще отказаться от разбиения больших методов да и классы не нужны.
Нужна одна огромная процедура и все должно в инлайнится. А то на вызовах методов теряем кучу времени
и солнце б утром не вставало, когда бы не было меня
