Здравствуйте, alex_public, Вы писали:

_>>>Код же на boost'е выше можно подправить под это условие парой букв.
Q>>Каких букв?
_>Там две лямбды (первая вызывается после каждого числа, а вторая после каждой строки). Из второй if убираем, а в первую добавляем. И всё. По объёму код даже не изменится.

Всё же конкретнее. Даже исходная формулировка задачи на русском была непростой для парсинга, пусть тут полежит законченный кусок на C++ для сравнения. Может, окажется, что я и условие-то неправильно понял.

Q>>Учёт предыдущих элементов обычно делается через зип со сдвигом.
_>А вот это и есть реальная жуть.

Усложнилась задача — усложнилось решение.

_>Причём исключительно из-за желания всунуть linq туда, куда оно не подходит.

У меня такого желания нет: «Императивный код на C# никто ведь не запрещает писать при необходимости». Просто предоставил требуемый вариант.

_>Тестировать быстродействие этого дела даже не буду — наверняка там что-то уже совсем печальное. )))

К тебе как эксперту по языкам

Автор: alex_public
Дата: 16.02.12

вопрос: есть представление об итераторах (yield return) в C#?

_>Т.к. когда у нас есть некий синтаксических сахар, позволяющий писать красивый код ценой некого падения быстродействия, то имеет смысл оценить размер этого падения (вдруг он допустимый для нашей задачи).

Можешь сформулировать, в чём заключается этот синтаксический сахар?

_>А тут у нас уже и код страшный — даже уже нет смысла смотреть что-то дальше.

Сложность кода возросла сообразно сложности задачи.

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Ну так я как раз вижу здесь создание новых сущностей, как я и предполагал.
НС>Не понял, что ты там видишь.

Создание массива строк.

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Только он отрицательные числа не учитывает. )
НС>Ну ты же понимаешь, что анализ минуса заметно на перформансе не скажется?

Не повлиял. Просто мне же надо было убедиться что программы выводят одно и тоже. ) Ну так, на всякий случай... )))

НС>Ну они не то чтобы прям тормоза, просто слишком примитивные. В джаве, кстати, такая же проблема — неиспользование BufferedStream одна из основных ошибок начинающих.

Хм, что-то я не уверен что там дело в примитивности. Больше ощущение что там что-то лишнее делается. Т.к. низкоуровневый C код работает без потерь скорости. Вообще лень копаться в этом уже, т.к. на практике я не использую ни то, ни другое. ))) Но для себя я однозначный вывод в тормознутость C++ потоков сделал.

НС>Ну, код в лоб я и на .NET написать могу.

Не сомневаюсь. Кстати, аналог этого раздела Boost'а для .Net тоже есть, сам видел. Так что в теории и на .Net возможен похожий вариант. Правда есть небольшой нюанс Boost — это стандарт де факто C++, постепенно переползающий в стандартную библиотеку, а для .Net я видел просто частное решение... Но в принципе возможно. Вот было бы интересно сравнить их по скорости — это было бы уже сравнения типа native vs. clr. ))) Но не охота, и так тема уже утомила, да и проблемность linq с которой всё началось уже всем показана.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Вот эта фраза:
НС>

НС>в xor должны попадать только числа или находящиеся на позиции не большей чем длинна предыдущей строки или стоящие после числа меньше их.

НС>по правилам русской грамматики не парсится.

A Qbit86 без проблем понял и даже умудрился втиснуть задачку в рамки linq. )))

НС>Pure function и pure functional это не одно и тоже.
НС>

НС>In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data.

Вот именно. ) Это именно парадигма. Причём большинство современных популярных языков являются мультипарадигменными. Например D поддерживает функциональную парадигму побольше многих и при этом не является декларативным. А Пролог — пример декларативного языка без функциональной парадигмы. Так что я не пойму зачем смешивать эти понятия.

НС>Что то я не пойму, в какой момент у тебя continuation monad превращается в sql?

С того момента, как это было задумано их создателями. )

НС>Реализация чего? Просто какого то DSL? В C# много подобных "DSL". Все из них являются sql? Или только какие то конкретные синтаксические конструкции? Какие и почему?
Я вроде бы всё очень конкретно написал. Читай внимательнее. )

НС>Какой синтаксический сахар ты имеешь в виду? По сравнению с С++ в тесте ровно одна новая конструкция — extension methods. К каким задачам он не подходит?
Синтаксический сахар может реализовываться не только самим языком, но и библиотеками. Вся linq — это один больший синтаксический сахар.

НС>extension methods никогда не приводят к потерям производительности, это просто статические методы, только синтаксис вызова похитрее. Или ты про лямбды?
Я про навязываемую архитектуру. Естественно умные люди просто не будут применять её в неподходящих случаях (или же будут, если их априори не волнует быстродействие в данном участке кода). Но боюсь очень многие используют просто не задумываясь что на таком подходе они замедляют код в разы, как мы уже видели в этой теме.

НС>Я не фанатик, но с появлением лямбд обязательно что то похожее появится. Хотя без замыканий, конечно, будет тяжко.

Вообще то они давно есть (и появились раньше linq), но используют их исключительно как синтаксический сахар к доступу на sql сервера. Как замену стандартным контейнерам никто даже и не думает использовать подобные конструкции.

Ну и с замыканиями то тоже проблем не видно — собственно мой код в этой теме их постоянно использовал.

НС>Неструктурированных данных. Я даже выделил жирным ключевое слово, но ты таки умудрился его проигнорировать.

Там разные есть и далеко не только ключ-значение. Посмотри внимательнее например MongoDB.

НС>Вот вот. Осталось задаться вопросом, почему ни одна ERP не использует эти новомодные map-reduce сотоварищи.

Когда я писал что эти технологии наступают, я не имел в виду что все бросились срочно переписывать свой код под новые принципы. Тем более такие монстры — у них переписывание кода по любому не окупиться. Процесс идёт по другому: новые проекты всё чаще и чаще берут за базис эти технологии. Так что не удивлюсь если какая-то новая ERP использует такой подход. А старые естественно пока остануся с sql. Слишком много в него уже вложено.

НС>Нет там лишнего копирования.

Судя по коду функции split более чем достаточно его.

_>> Потому что этот синтаксический сахар навязывает нам определённую архитектуру приводящую к лишним накладным расходам.
НС>Что именно он навязывает? Конкретно.

Провоцирует генерировать лишние промежуточные структуры данных (которые программист часто и не видит), которые реально и не нужны в решение данной задачи.

_>>Кстати, замечу что если программировать на stl в её функциональном стиле, то опять же натыкаемся на похожие проблемы.
НС>Мы натыкаемся на гораздо большее количество проблем, с чего, собственно, этот тред и начался.

Где больше то? Размер и читабельность кода одинаковая, быстродействие выше. Где большие проблемы?

_>> А вот при использование всяческих boost хитростей или же написание императивного кода действующего в лоб уже никаких потерь нет.
НС>Если это всегда выливается в тот ужас ужас, что ты продемонстрировал, то такое надо применять только в сверхкрайних случаях.

На самом деле это всего лишь Форма Бэкуса—Наура адаптированная под C++ синтаксис. Так что никакого "ужас ужас" для хотя бы раз взглянувших на документацию библиотеки там нет.

_>> И кстати при этом boost код ещё и короче всех рассмотренных вариантов вообще.
НС>Ну еще бы, если все в одну строчку запихать.

linq пример помнится был вообще в одну строку, только такую, что её пришлось перенести мнооого раз. )))

Здравствуйте, Qbit86, Вы писали:

Вот ты будешь смеяться, но пока я писал Ночному Смотрящему про недостатки навязываемые linq, то понял что я сам умудрился засунуть подобный недостаток (хотя и мелкий совсем) даже в код с Boost'ом! Вот до чего доводить копипаст и автоматическая работа, вместо того что бы на секунду задуматься. Естественно там не нужен никакой промежуточный вектор (он пришёл копипастом из stl кода) и вся эта фигня с алгоритмами. Даже не представляю как я мог ТАКУЮ ерунду пропустить, устал видимо. Или же вредное влияние linq коснулось уже и меня и надо скорее заканчивать это обсуждение, пока совсем не заразился.))) Поправил код сейчас. И что самое забавное, особо быстрее он конечно не стал, но зато стал намного проще и читабельнее. Вот нормальный вариант:

multiset<int> result;
int xor=0, count=0;
parse(buf.get(), buf.get()+size,
    (*(int_[[&](int n,...){xor^=n; count++;}] % ',' >> -eol)[[&](...){if(count>2) result.insert(xor); count=xor=0;}]));
for(auto i=result.crbegin(); i!=result.crend(); ++i) cout<<*i<<endl;

Q>Всё же конкретнее. Даже исходная формулировка задачи на русском была непростой для парсинга, пусть тут полежит законченный кусок на C++ для сравнения. Может, окажется, что я и условие-то неправильно понял.

Что касается нового варианта, то раз вектора у нас уже нет, то придётся не только if подвинуть, но и переменную добавить, ну и на этом всё:

multiset<int> result;
int xor=0, count=0, prev=0, prev_count=0;
parse(buf.get(), buf.get()+size,
    (*(int_[[&](int n,...){if(++count<=prev_count||n>prev) xor^=n; prev=n;}] % ',' >> -eol)[[&](...){result.insert(xor); prev_count=count; prev=count=xor=0;}]));
for(auto i=result.crbegin(); i!=result.crend(); ++i) cout<<*i<<endl;

Q>Усложнилась задача — усложнилось решение.
Да не настолько то она усложнилась. Ну условие чуть другое, немного сложнее, но это же не повод что бы писать ТАКИЕ многоэтажные конструкции.

Q>У меня такого желания нет: «Императивный код на C# никто ведь не запрещает писать при необходимости». Просто предоставил требуемый вариант.

Я прекрасно понимаю что ты не стал бы писать такое в реальности, а сделал бы нормальный императивный код. Просто тогда тебе осталось честно признать что есть много задач на которые linq парадигма плохо ложиться. Как я собственно и утверждал в самом начале, посмотрев на неё.

Q>К тебе как эксперту по языкам

Автор: alex_public
Дата: 16.02.12

вопрос: есть представление об итераторах (yield return) в C#?

Такое же как в Питоне? Оно частенькое используется у нас в серверном коде)

Q>Можешь сформулировать, в чём заключается этот синтаксический сахар?

SQL подобный синтаксис обработки коллекций.

Q>Сложность кода возросла сообразно сложности задачи.

Даже близко не сравнимо.

Здравствуйте, alex_public, Вы писали:

_>A Qbit86 без проблем понял и даже умудрился втиснуть задачку в рамки linq. )))

Ну, я не сказал бы, что понял без проблем :)

НС>>Хотя без замыканий, конечно, будет тяжко.
_>Ну и с замыканиями то тоже проблем не видно — собственно мой код в этой теме их постоянно использовал.

Лямбды в C++ не решают upwards funarg problem, поэтому не могут считаться полноценными замыканиями.

_>linq пример помнится был вообще в одну строку, только такую, что её пришлось перенести мнооого раз. )))

Нет, то был один statement, разбитый на несколько строк для выделения логических единиц. (Это как раз противоположно тому, чтобы запихнуть много statement'ов в одну строку.) Такой «конвейер» вполне типичен для ФЯПов, см., например, оператор |> в F# или его (противоположно направленного) коллегу $ из Haskell. В C++ аналогом такой конструкции мог бы служить operator <<().

Здравствуйте, alex_public, Вы писали:

_>

multiset<int> result;
_>int xor=0, count=0, prev=0, prev_count=0;
_>parse(buf.get(), buf.get()+size,
_>    (*(int_[[&](int n,...){if(++count<=prev_count||n>prev) xor^=n; prev=n;}] % ',' >> -eol)[[&](...){result.insert(xor); prev_count=count; prev=count=xor=0;}]));
_>for(auto i=result.crbegin(); i!=result.crend(); ++i) cout<<*i<<endl;

Q>>Усложнилась задача — усложнилось решение.
_>Да не настолько то она усложнилась. Ну условие чуть другое, немного сложнее, но это же не повод что бы писать ТАКИЕ многоэтажные конструкции.

Так в плюсовом варианте не менее многоэтажная конструкция, просто записана в одну строку.

_>>>Тестировать быстродействие этого дела даже не буду — наверняка там что-то уже совсем печальное. )))
Q>>К тебе как эксперту по языкам

Автор: alex_public
Дата: 16.02.12

вопрос: есть представление об итераторах (yield return) в C#?
_>Такое же как в Питоне? Оно частенькое используется у нас в серверном коде)

И что в этих итераторах печального?

_>>>Т.к. когда у нас есть некий синтаксических сахар, позволяющий писать красивый код ценой некого падения быстродействия, то имеет смысл оценить размер этого падения (вдруг он допустимый для нашей задачи).
Q>>Можешь сформулировать, в чём заключается этот синтаксический сахар?
_>SQL подобный синтаксис обработки коллекций.

Так я его не использовал. Я использовал простые конструкции типа «вызов метода», «анонимный метод», etc. Даже если б использовал сахар, то CLR всё равно о нём ничего не знает, компилирует всё в обычные вызовы, в чём можно убедиться, декомпилировав сборку в Рефлекторе. В чём здесь выразится падение быстродействия fluent-вызовов («цепочки», «конвейера») «x.h().g().f()» по сравнению с вложенными вызовами «(f(g(h(x))))»?

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, _d_m_, Вы писали:

___>>Это просто модные тенденции, которые имеют под собой в основе то, что большинство потребителей данной продукции не смогли осилить SQL.

_>Ну да, конечно, всякие там гуглы, амазоны, фейсбуки, яндексы — это просто неумехи. Они хотели бы на mysql построить свои системы, но не осилили просто. Поэтому пришлось городить свои велосипеды. )))

На чем на чем? На самом говне из всех SQL-ей — на MySQL?
А таки гугли лепили себе узкоспециализированое решение, и дешевле им было сваять с нуля, чем покупать лицензии у каких-нибудь Ораклов, МС или АйБиЭм. Ну если ты пишешь второй гугль — то тогда канешна... Флаг в руки и электричка навстречу

_>А теперь уже и мелкие системы идут по тому же пути, только используя не свои велосипеды, а коллективные разработки или же подаренные теми же корпорациями. Естественно вовсе не потому что nosql решения могут держать большую нагрузку и проще масштабироваться, а просто по глупости — обезьянничают со старших коллег. )))

+500
Даже людям с альтернативным развитием приходят в голову умные мысли. Только они думают, что это полный идиотизм

Здравствуйте, Qbit86, Вы писали:

Q>Лямбды в C++ не решают upwards funarg problem, поэтому не могут считаться полноценными замыканиями.

Хы, ну в C++ все уже привыкли сами следить за ресурсами, организовавать ROII, знать что выделять на стеке. Так что это не проблема. Как видно из моих примеров тут замыкания используются по полной и всё очень удобно.

Q>Нет, то был один statement, разбитый на несколько строк для выделения логических единиц. (Это как раз противоположно тому, чтобы запихнуть много statement'ов в одну строку.) Такой «конвейер» вполне типичен для ФЯПов, см., например, оператор |> в F# или его (противоположно направленного) коллегу $ из Haskell. В C++ аналогом такой конструкции мог бы служить operator <<().

Да я понял. Кстати в Boost такой конвеер задаётся оператором |. Просто я не люблю организовывать такие длинные выражения. И одновременно не люблю переносить одно выражение на несколько строк. Мне приятнее написать допустим 2 выражения на 2 строки. Но это мои личные вкусовые пристрастия. И я для примера написал последний Boost пример уже в виде одного выражения на несколько строк (т.е. не в своём стиле). Хотя там без проблем можно 2 лямбды выделить в отдельные выражения.

Здравствуйте, Qbit86, Вы писали:

Q>Так в плюсовом варианте не менее многоэтажная конструкция, просто записана в одну строку.

Эээ, она почти не изменилась с предыдущими примером. Т.е. у нас ситуация следующая:
Первый пример — linq код красив, boost код читаем
Второй пример — linq код дико ужасен, boost код практически не изменился.

Об этом и была речь. И я думаю что никто не сомневается что можно придумать ещё множество условий приводящих к ещё более печальной ситуации с linq.

Q>И что в этих итераторах печального?

Ничего печального) yield — очень хорошая и удобная вещь.

Q>Так я его не использовал. Я использовал простые конструкции типа «вызов метода», «анонимный метод», etc. Даже если б использовал сахар, то CLR всё равно о нём ничего не знает, компилирует всё в обычные вызовы, в чём можно убедиться, декомпилировав сборку в Рефлекторе. В чём здесь выразится падение быстродействия fluent-вызовов («цепочки», «конвейера») «x.h().g().f()» по сравнению с вложенными вызовами «(f(g(h(x))))»?

Оооооооооооооооох. Я же вроде бы уже десяток раз в этой темке ткнул в нужное место.

Там для каждой строки файла создаётся массив строк представляющих собой отдельные числа — для решения этой задачи он вообще не нужен. Но не создавая его не получится использовать linq, а придётся писать тупой императивный код. Вот и всё. Причём это только для начала. Возможно там внутри и ещё что-то создаётся (я же во внутренностях не лазил, не знаю), например массив интов перед агрегацией, хотя уже не факт, надо смотреть.

А больше всего меня забавляет что со мной спорят именно по этому вопросу. Смотри, у нас есть неоспоримый экспериментальный факт тормознутости linq кода в 5 (!!!) раз по сравнению с C++. Я пытаюсь хоть как-то объяснить его происхождение, хотя это как бы не моё дело — мне достаточно самого экспериментального факта, т.к. я то со стороны C++ смотрю. Но со мной не соглашаются, при этом не выдвигая никаких своих вариантов. Ну предположим что я не прав и парадигма навязываемая linq ни при чём. Что тогда то? Просто сам clr и .net кривые и тормознутые что ли? Или что? )))

Здравствуйте, _d_m_, Вы писали:

___>На чем на чем? На самом говне из всех SQL-ей — на MySQL?

Это была ирония. ))) Раз трудности даже с пониманием этого, то беседовать дальше просто бесполезно. )

Здравствуйте, alex_public, Вы писали:

_>Эээ, она почти не изменилась с предыдущими примером. Т.е. у нас ситуация следующая:
_>Первый пример — linq код красив, boost код читаем
_>Второй пример — linq код дико ужасен, boost код практически не изменился.

Ну, это субъективные оценочные суждения :)

_>Оооооооооооооооох. Я же вроде бы уже десяток раз в этой темке ткнул в нужное место.
_>Там для каждой строки файла создаётся массив строк представляющих собой отдельные числа — для решения этой задачи он вообще не нужен.

Так это к Linq'у вообще никакого отношения не имеет, к синтаксическому сахару какому-то тем более. String.Split() из Framework Class Library — это первый попавшийся под руку кондовый прямолинейный метод из, емнип, ещё до'generic'овой эпохи .NET, когда Linq'а и в помине не было.

_>Возможно там внутри и ещё что-то создаётся (я же во внутренностях не лазил, не знаю), например массив интов перед агрегацией, хотя уже не факт, надо смотреть.

Код методов-расширений из Linq чудовищно простой и катастрофически прямолинейный. Например,

public static TAccumulate Aggregate<TSource, TAccumulate>(
  this IEnumerable<TSource> source, TAccumulate seed, Func<TAccumulate, TSource, TAccumulate> func)
{
  if (source == null)
  {
    throw Error.ArgumentNull("source");
  }
  else if (func == null)
  {
    throw Error.ArgumentNull("func");
  }
  else
  {
    TAccumulate accumulate = seed;
    foreach (TSource source1 in source)
      accumulate = func(accumulate, source1);
    return accumulate;
  }
}

_>А больше всего меня забавляет что со мной спорят именно по этому вопросу. Смотри, у нас есть неоспоримый экспериментальный факт тормознутости linq кода в 5 (!!!) раз по сравнению с C++.

Доказательство в духе «Как вы можете не верить, что я, Мюнхгаузен, вытащил себя за косичку из болота? Вот же я, живой!» Т.е. ты свои измерения трактуешь произвольно.

_>Но со мной не соглашаются, при этом не выдвигая никаких своих вариантов.

Ты переоцениваешь желание собеседников профилировать библиотечный код и что-то там доказывать про призводительность.

_>Ну предположим что я не прав и парадигма навязываемая linq ни при чём. Что тогда то? Просто сам clr и .net кривые и тормознутые что ли? Или что? )))

Это вопросы к Ants Memory Profiler.

Здравствуйте, Qbit86, Вы писали:

Q>Так это к Linq'у вообще никакого отношения не имеет, к синтаксическому сахару какому-то тем более. String.Split() из Framework Class Library — это первый попавшийся под руку кондовый прямолинейный метод из, емнип, ещё до'generic'овой эпохи .NET, когда Linq'а и в помине не было.

Ох. Да дело не в быстродействие split. Вы можете хоть заоптимизировать её, но всё равно будут те же проблемы. Дело в том, что для применения linq методов вам необходима коллекция, пускай даже и ленивая. Поэтому её надо как-то обязательно создать. В данном случае это делает split (и возможно оно действительно не такое быстрое как могло бы быть), но в принципе это не важно. Главное сам факт существования этой коллекции, потому что если реально посмотреть на задачу, то никакие коллекции кроме начального массива данных и итогового (и то только для сортировки) нам не нужны! Но мы создаём промежуточные, что бы использовать linq.

Так что вы можете вылизывать подобный код сколько угодно, заменить все функции своими вариантами, но пока хотите работать в парадигме linq у вас по любому будет провал в производительности на подобных задачах.

Хотя как я уже писал для многих случаев это вполне терпимо.

Q>Доказательство в духе «Как вы можете не верить, что я, Мюнхгаузен, вытащил себя за косичку из болота? Вот же я, живой!» Т.е. ты свои измерения трактуешь произвольно.

Я вообще то все коды здесь выкладывал — любой может повторить. Если у кого проблемы с компилятором C++ или Бустом, то могу выложить exe. Каждый может убедиться сам.

Q>Это вопросы к Ants Memory Profiler.

Ну в любом случае это не ко мне. Мне достаточно что я знаю распределение в C++ коде и знаю что он быстрее .Net варианта в 5 раз. Остальное оставлю другим экспериментаторам.

И вообще думаю что пора завершить дискуссию. В данный момент мне кажется что мы наконец то до конца поняли позиции друга друга и все обоснования позиций. И даже умудрились отбросить всякие оскорбительные выпады, перейдя к более менее конструктивному диалогу. Правда этого оказалось недостаточно что бы одна из сторон публично признала правоту другой, ну да ладно, хотя бы так. )))

Здравствуйте, alex_public, Вы писали:

_>Вот именно. ) Это именно парадигма.

И?

_> Причём большинство современных популярных языков являются мультипарадигменными.

И?

_>А Пролог — пример декларативного языка без функциональной парадигмы.

И?

_> Так что я не пойму зачем смешивать эти понятия.

А кто их смешивает? Ты хвостом то не верти — я тебе пытался объяснить одну простую вещь: чистый функциональный стиль декларативен по определению. При чем тут парадигма, популярные языки и Пролог?

НС>>Что то я не пойму, в какой момент у тебя continuation monad превращается в sql?
_>С того момента, как это было задумано их создателями. )

Т.е. с 91 года, когда монады появились в ФП? Или еще раньше, когда одноименное понятие появилось в теории категорий?

НС>>Реализация чего? Просто какого то DSL? В C# много подобных "DSL". Все из них являются sql? Или только какие то конкретные синтаксические конструкции? Какие и почему?
_>Я вроде бы всё очень конкретно написал.

Нет, ты не написал ничего конкретного. Единственная фраза была про то, что виноват linq. Но linq это не синтаксическая конструкция, это просто маркетинговый бренд. Поэтому еще раз — какие конкретно элементы синтаксиса C# ответственны за превращение в SQL и тормоза?

НС>>Какой синтаксический сахар ты имеешь в виду? По сравнению с С++ в тесте ровно одна новая конструкция — extension methods. К каким задачам он не подходит?
_>Синтаксический сахар может реализовываться не только самим языком, но и библиотеками.

В C# не может, там метапрограммирования нет даже в том страшном виде, в каком оно есть в С++. Так что никаких библиотек. Да если бы и библиотеки — я тебе почти все использованные методы класса Enumerable воспроизведу на коленке за 10 минут.
К примеру:

public static IEnumerable<T> Where<T>(this IEnumerable<T> src, Func<T, bool> predicate)
{
  foreach (var item in src)
      if (predicate(item))
          yield return item;
}

public static IEnumerable<P> Select<T,P>(this IEnumerable<T> src, Func<T, P> projector)
{
  foreach (var item in src)
        yield return projector(src);
}

Что здесь SQL? Что здесь тормозит? Если вместо IEnumerable<T> аргументом для query pattern будет T[], а внутри вместо foreach будет обычный for, это все равно будет SQL?

А больше там ничего хоть отдаленно имеющего отношение к LINQ нет.

_> Вся linq — это один больший синтаксический сахар.

Предположим. Так что конкретно там тормозит? Или тормозят вообще все нововведения в C# 3?

НС>>extension methods никогда не приводят к потерям производительности, это просто статические методы, только синтаксис вызова похитрее. Или ты про лямбды?
_>Я про навязываемую архитектуру.

Моя твоя не понимать. Какую такую архитектуру?

_> Естественно умные люди просто не будут применять её в неподходящих случаях (или же будут, если их априори не волнует быстродействие в данном участке кода).

Мммм. Я дождусь, наконец, от тебя конкретики? Что конкретно, по твоему, тормозит?

_> Но боюсь очень многие используют просто не задумываясь что на таком подходе они замедляют код в разы, как мы уже видели в этой теме.

Ты даже не представляешь как часто и как глубоко я задумывался над такими вопросами как на прошлой работе, так и на текущей. А последние пару месяцев я большую часть рабочего времени занимаюсь исключительно перформансом.

_>Вообще то они давно есть

Лямбды? В предыдущем С++? Ты о чем? Об изврате из буста что ли? Это не лямбды, это плохая пародия на них.

_>но используют их исключительно как синтаксический сахар к доступу на sql сервера.



_> Как замену стандартным контейнерам никто даже и не думает использовать подобные конструкции.

Ты о чем вообще? Нить разговора не потерял?

НС>>Неструктурированных данных. Я даже выделил жирным ключевое слово, но ты таки умудрился его проигнорировать.
_>Там разные есть и далеко не только ключ-значение. Посмотри внимательнее например MongoDB.

Да пофигу что там есть. Ты попробуй перечитать топик чуть вверх. Успешные применения таких баз только там, где структура данных простая или нечеткая.

НС>>Вот вот. Осталось задаться вопросом, почему ни одна ERP не использует эти новомодные map-reduce сотоварищи.
_>Когда я писал что эти технологии наступают, я не имел в виду что все бросились срочно переписывать свой код под новые принципы.

А что тогда понимается под наступлением? Количество пиара на всяких фрикерских эвентах?

_>Процесс идёт по другому: новые проекты всё чаще и чаще берут за базис эти технологии.

Какой ERP проект взял за базис nosql хранилище? Есть что нибудь кроме персистентного кеша веб-приложений или индексов различных поисковиков и майнеров?

_> Так что не удивлюсь если какая-то новая ERP использует такой подход.

Зато я удивлюсь. Так факты будут?

_>>> Потому что этот синтаксический сахар навязывает нам определённую архитектуру приводящую к лишним накладным расходам.
НС>>Что именно он навязывает? Конкретно.

_>Провоцирует генерировать лишние промежуточные структуры данных

Какие? Вот в примере — какая структура данных лишняя?

НС>>Мы натыкаемся на гораздо большее количество проблем, с чего, собственно, этот тред и начался.
_>Где больше то? Размер и читабельность кода одинаковая

Ну, если только ну очень захотеть. А так — читать твой код практически невозможно. Каша.

НС>>Ну еще бы, если все в одну строчку запихать.
_>linq пример помнится был вообще в одну строку, только такую, что её пришлось перенести мнооого раз. )))

Еее не пришлось перенести, ее специально перенесли, чтобы легко читать было. Результат — такой код легко понятен даже тем, кто с С№ совсем не знаком. А вот в твоей каше с первого взгляда не разберешься.

Здравствуйте, alex_public, Вы писали:

НС>>Не понял, что ты там видишь.

_>Создание массива строк.

А что взамен? Range хранить? Ну можно. Только тогда придется и парсинг на эти range переделать. А самое интересное — тот код, который Qbit привел, от этого не изменится. Просто подставятся другие реализации Split и Parse. Так что тема фатальных проблем в LINQ не раскрыта.

Здравствуйте, alex_public, Вы писали:

_>Не повлиял. Просто мне же надо было убедиться что программы выводят одно и тоже. ) Ну так, на всякий случай... )))

Это все полнейшая ерунда. Куда интереснее другое — ты даже в теории не предполагал, что основные проблемы в методе int.Parse.

_>Хм, что-то я не уверен что там дело в примитивности. Больше ощущение что там что-то лишнее делается.

Так как раз не делается. Не делается нормальная буферизация.

_>да и проблемность linq с которой всё началось уже всем показана.

Не знаю кому она там показана, но я пока от тебя так и не добился внятного ответа, в чем же linq провинился конкретно.

Здравствуйте, alex_public, Вы писали:

_>Но не создавая его не получится использовать linq

Получится.

_>А больше всего меня забавляет что со мной спорят именно по этому вопросу. Смотри, у нас есть неоспоримый экспериментальный факт тормознутости linq кода в 5 (!!!) раз по сравнению с C++.

Как оказалось, все таки в 2 раза.

Здравствуйте, alex_public, Вы писали:

_>Ох. Да дело не в быстродействие split. Вы можете хоть заоптимизировать её, но всё равно будут те же проблемы.

Какие и почему?

_> Дело в том, что для применения linq методов

Нет никаких linq методов. Есть класс Enumerable, но он, по большей части, тривиален.

_> вам необходима коллекция, пускай даже и ленивая

Нет, коллекция не нужна, только энумератор. А можно и свой аналог написать, вообще исключительно со своими типами.

_>. Поэтому её надо как-то обязательно создать.

Энумератор это, логически, просто указатель на элемент коллекции, это не сама коллекция, ничего ужасного в его создании 1 раз нет.

_>Но мы создаём промежуточные, что бы использовать linq.

Вывод неверный. Промежуточный массив создает метод Split, который никакого отношения к linq не имеет. А без массива индексов, который создает внутри OrderBy, ты и руками сортировку не сделаешь.

_>И вообще думаю что пора завершить дискуссию. В данный момент мне кажется что мы наконец то до конца поняли

Тебе кажется.

Здравствуйте, Ночной Смотрящий, Вы писали:

Меня если честно утомил твой стиль дискуссии, когда 40% твоих вопросов уже имеют ответ раньше, ответ на ещё 40% находится в сообщение для другого человека ниже по теме (что, сложно дочитать тему до конца, прежде чем написать десятки вопросов, и увидеть там ответ?) и только 20% текста несут что-то новое. Так что я в этот раз не буду цитировать все эти бесконечные простыни демагогии и отвечу только на реально новое.

НС>Ты даже не представляешь как часто и как глубоко я задумывался над такими вопросами как на прошлой работе, так и на текущей. А последние пару месяцев я большую часть рабочего времени занимаюсь исключительно перформансом.

Сомнительно. Т.к. в этом случае для нашего конкретного примера и при условии заточки на производительность ты бы просто не стал брать linq вообще.

НС>А что взамен? Range хранить? Ну можно. Только тогда придется и парсинг на эти range переделать. А самое интересное — тот код, который Qbit привел, от этого не изменится. Просто подставятся другие реализации Split и Parse. Так что тема фатальных проблем в LINQ не раскрыта

Ох, как же головы любителей linq затуманены этим сахаром, если не видят очевидного. И Range хранить не надо. Более того, даже изначальное разделение файла на коллекцию из строк не нужно, т.к. оно приводит к лишнему проходу по данных. Ладно, сейчас объясню так, что точно поймёшь.

Напиши на C# тупой императивный код (на C++ мне для этого минута наверное понадобилась) реализующий следующее (упрощённо, на своебразном псевдокоде):

загрузить файл в buf
цикл по buf{
    если текущий элемент:
    ',' то xor^=преобразования к int текущего куска buf; count++
    '\n' то xor^=преобразования к int текущего куска buf; count++; если count>2 добавить xor в отсортированый массив result; обнулить xor;
}
вывести result

Так вот, думаю что такой вариант будет уступать по скорости C++ уже точно не в разы. И ты видишь тут какой-нибудь массивы строк или range или вообще какие либо дополнительные сущности кроме начальных данных и итоговой коллекции? Это и есть оптимальный код, не привносящий ничего лишнего ради синтаксического сахара.

Другое дело что подобный код некрасивый, низкоуровневый, неудобно расширяемый, так что использовать его есть смысл только если вопрос о производительности критичен. А в остальных случаях (естественно если задача ложится на sql синтаксис вообще — как мы видели по второму примеру это тоже далеко не всегда) использование linq вполне логично.

Для C++ Boost решает проблему для подобных задач, предоставляя универсальное высокоуровневое решение, не требующее создания лишних сущностей.

НС>Вывод неверный. Промежуточный массив создает метод Split, который никакого отношения к linq не имеет. А без массива индексов, который создает внутри OrderBy, ты и руками сортировку не сделаешь.

К результирующему массиву никаких претензий нет — он есть и в C++ варианте и является следствием пункта о сортировке в условиях задачи. А вот без какой-либо разновидности split написать на linq решение этой задачи не выйдет.

НС>Тебе кажется.

Вообще то я писал Qbit86. Но собственно теперь это можно уже обобщить на всю тему. Я уже не просто сказал всё, я это повторил по несколько раз в разных формулировках. Наедоло. Если кто-то до сих пор и не понял, то мне уже всё равно. )))

Здравствуйте, alex_public, Вы писали:

_>Меня если честно утомил твой стиль дискуссии

Когда требуют фактов, которых нет, согласен, это неприятно

_>Так что я в этот раз не буду цитировать все эти бесконечные простыни демагогии

Перевожу — проигнорирую все неудобные вопросы. Ты поскипал (ожидаемо) все конкретные вопросы, оставил только то, на что можно растечься мыслью по древу.

НС>>Ты даже не представляешь как часто и как глубоко я задумывался над такими вопросами как на прошлой работе, так и на текущей. А последние пару месяцев я большую часть рабочего времени занимаюсь исключительно перформансом.

_>Сомнительно. Т.к. в этом случае для нашего конкретного примера и при условии заточки на производительность ты бы просто не стал брать linq вообще.

Предположение неверное.

НС>>А что взамен? Range хранить? Ну можно. Только тогда придется и парсинг на эти range переделать. А самое интересное — тот код, который Qbit привел, от этого не изменится. Просто подставятся другие реализации Split и Parse. Так что тема фатальных проблем в LINQ не раскрыта

_>Ох, как же головы любителей linq затуманены этим сахаром, если не видят очевидного.

А ты не допускаешь, что сам чего то не видишь?

_>Напиши на C# тупой императивный код (на C++ мне для этого минута наверное понадобилась) реализующий следующее (упрощённо, на своебразном псевдокоде):
_>

загрузить файл в buf
_>цикл по buf{
_>    если текущий элемент:
_>    ',' то xor^=преобразования к int текущего куска buf; count++
_>    '\n' то xor^=преобразования к int текущего куска buf; count++; если count>2 добавить xor в отсортированый массив result; обнулить xor;
_>}
_>вывести result

_>Так вот, думаю что такой вариант будет уступать по скорости C++ уже точно не в разы.

Вот только это тоже можно переписать в стиле линка, не потеряв в скорости. Именно поэтому я 50 раз спросил, что конкретно, по твоему, тормозит. И ты так упорно не хочешь отвечать потому что ответа то ты и не знаешь.

_>А в остальных случаях (естественно если задача ложится на sql синтаксис вообще

Напоминаю, ты так и не смог рассказать, что же ты понимаешь под "sql синтаксиcом".

_>К результирующему массиву никаких претензий нет — он есть и в C++ варианте и является следствием пункта о сортировке в условиях задачи. А вот без какой-либо разновидности split написать на linq решение этой задачи не выйдет.

Но split не обязан что либо копировать. И уж точно не имеет отношения к линку.

_>Вообще то я писал Qbit86. Но собственно теперь это можно уже обобщить на всю тему

Не надо ничего обощать, пока у тебя нет конкретики.

_>. Я уже не просто сказал всё, я это повторил по несколько раз в разных формулировках. Наедоло. Если кто-то до сих пор и не понял, то мне уже всё равно. )))

Это называется "не смогла".