Представьте таблицу order. В ней есть state. База оч старая, 97% записей в таблице имеют State = 'Executed', всего 6 статусов.
А теперь представьте, мы сутра выполняем дважды запрос
select * from t_order where state = :a
с a: = 'Executed' и a: = 'InTransit'
При выполнении первого запроса оракл создаст для него план, который конечно же сделает фулл скан.
А при выполнении второго запроса план будет пере использован. И мы получим фулл скан на ровном месте, т.к. у оракла есть гистограмма, и он знает что select * from t_order where state = 'InTransit' дает где то 0,5% записей.
Если говорить о скорости, тут же тоже зависит от задачи. Если у вас тысячи запросов в секунду, выполняющихся доли секунды, то время на разбор может ролять. А если у вас запрос в минуту, идущий н секунд, то время разбора запроса пренебрежительно мало, а вот план становится очень важен.
Понятно, что отказ от байнд переменных не идеальное решение, в частности оно сильно затрудняет анализ нагрузки на базу. Но говорить что для всех ситуаций с байнд переменным будет быстрее не верно.
Изменять только что сгенерированные сущности действительно не оптимально. Но почему вы сузили круг вопросов до только что сгенерированных? Я достал сущностями из базы, написал ещё пару дополнительных Where и пошел делать над ними операции.
Entity — в DDD по определению мутабельна. Почитайте Эванса. Может быть вы сущностями называете все на свете классы?
Инженерные дисциплины — не точные науки. Здесь мы выбираем разумный компромисс. В большинстве задач действительно допустимо считать IEnumerable конечным. Но вот если мы начинаем работать с ним как с массивом — тогда у нас могут быть проблемы.
Причем я говорю не о том, что проблемы могут быть «вообще»(вообще они могут быть и если считать IEnumerable конечным), а о том, что я неоднократно сталкивался с ними в реальных проектах.
По этому вызвать Last() здесь, на мой взгляд, допустимо. А вот lines.ElementAt(lines.Count()) — нет т.к. это две енумерации, и мы здесь предполагаем не только конечность, но и дешевизну енумераций.
Ну примерно об этом с и постарался рассказать. Вы привели первый абзац выводов. А во втором как раз и говорится, что если необходим перебор элементов и не более — то это и есть единственно допустимый случай использования IEnumerable.
По поводу частоты использования — мне, к сожалению, в реальных проектах чаще встречаются «неправильные» использования IEnumerable. А подсказка решарпера, о которой говорил hVostt сильно подливает масла в огонь.
А что Вы называете функциональщиной? LINQ? Тогда я просто не могу её не мешать с мутабельными типами. Я занимаюсь разработкой корпоративных приложений и по этому большинство классов с которыми я имею дело — сущности. А они по определению мутабельны. И конечно же к ним полно LINQ запросов…
Кстати, я не говорю что в примерах написал идеальный код. единственная проблема которого — злобный IEnumerable :)
var bars = GeBarstFromKamchatkaDbInstance()
var censored = Censure(bars);
foreach(var current in censored)
{
Print(current);
}
PrintFooter(curent.Count())
Как исключить риск подобной ошибке с применением функциональной парадигмы? И что в первом примере концептуально не соответствует функциональной парадигме?
Вот вы начали грузить статьи, они попали в нулевое поколение, прямую ссылку на них убрали. Нагрузили таких статей 256 кб. Прошла сборка мусора, ваш кэш пуст…
WeakReference нельзя использовать для кэша. По сути, уходить сущности из вашего кэша будут не по мере заполнения памяти, а в случайные моменты времени.
Посмотрите в сторону System.Runtime.Caching
msdn.microsoft.com/ru-ru/library/ms404247.aspx
Avoid using weak references as an automatic solution to memory management problems. Instead, develop an effective caching policy for handling your application's objects.
Отличная статья. А то я вчера прочел про то как человеку впаривают автотестирование на его небольшие веб проекты, что мне аж плохо стало… Теперь баланс добра и зла восстановлен.
А теперь представьте, мы сутра выполняем дважды запрос
select * from t_order where state = :a
с a: = 'Executed' и a: = 'InTransit'
При выполнении первого запроса оракл создаст для него план, который конечно же сделает фулл скан.
А при выполнении второго запроса план будет пере использован. И мы получим фулл скан на ровном месте, т.к. у оракла есть гистограмма, и он знает что select * from t_order where state = 'InTransit' дает где то 0,5% записей.
Если говорить о скорости, тут же тоже зависит от задачи. Если у вас тысячи запросов в секунду, выполняющихся доли секунды, то время на разбор может ролять. А если у вас запрос в минуту, идущий н секунд, то время разбора запроса пренебрежительно мало, а вот план становится очень важен.
Понятно, что отказ от байнд переменных не идеальное решение, в частности оно сильно затрудняет анализ нагрузки на базу. Но говорить что для всех ситуаций с байнд переменным будет быстрее не верно.
Не совсем верно.
>И напоследок – используйте связанные переменные! Это позволит разом значительно, часто в несколько раз увеличить производительность
Или замедлить, на порядки…
Последняя ссылка в посте.
Entity — в DDD по определению мутабельна. Почитайте Эванса. Может быть вы сущностями называете все на свете классы?
Причем я говорю не о том, что проблемы могут быть «вообще»(вообще они могут быть и если считать IEnumerable конечным), а о том, что я неоднократно сталкивался с ними в реальных проектах.
По этому вызвать Last() здесь, на мой взгляд, допустимо. А вот lines.ElementAt(lines.Count()) — нет т.к. это две енумерации, и мы здесь предполагаем не только конечность, но и дешевизну енумераций.
По поводу частоты использования — мне, к сожалению, в реальных проектах чаще встречаются «неправильные» использования IEnumerable. А подсказка решарпера, о которой говорил hVostt сильно подливает масла в огонь.
Кстати, я не говорю что в примерах написал идеальный код. единственная проблема которого — злобный IEnumerable :)
Как исключить риск подобной ошибке с применением функциональной парадигмы? И что в первом примере концептуально не соответствует функциональной парадигме?
Tue Jul 09 12:54:00 2013 Application started. Hello, World!
Tue Jul 09 12:54:00 2013 Application version: 0.0.6.365 Release
Tue Jul 09 12:54:00 2013 Starting renderer initialization
Tue Jul 09 12:54:00 2013 SDL successfully initialized
Tue Jul 09 12:54:00 2013 Video mode set
Tue Jul 09 12:54:00 2013 OpenGL version: 1.5.0 — Build 6.14.10.4847
Tue Jul 09 12:54:00 2013 Loading textures…
Tue Jul 09 12:54:00 2013 Successfully loaded res/font2.png
Tue Jul 09 12:54:00 2013 Successfully loaded res/gui.png
Tue Jul 09 12:54:00 2013 Finished loading textures.
Tue Jul 09 12:54:00 2013 Initialization successfully completed
Tue Jul 09 12:54:00 2013 Switching to menu
error.log:
Tue Jul 09 12:54:00 2013 OpenGL error during main loop. Something bad happened OpenGL error: 1281
«Assertion failed!
Program: C:\Games\Box2D\Engine.dll
File: auxFuncs.cpp
Line: 39
Expression: err == 0»
Если нажать «пропустить», то вроде работает, но шрифт, видимо, не прогрузился. Надписи отсутствуют
Посмотрите в сторону System.Runtime.Caching
msdn.microsoft.com/ru-ru/library/ms404247.aspx
Avoid using weak references as an automatic solution to memory management problems. Instead, develop an effective caching policy for handling your application's objects.