Оптимизация и целесообразность LINQ запроса

@5665tm · Регистрация: 17.06.2013

Author24 — интернет-сервис помощи студентам

Добрый день. Решил воткнуть Linq в свой курсач, просто для саморазвития, потому что до этого не работал с ним ни разу

Без Linq

Кликните здесь для просмотра всего текста

C#

                List<Session> search_list = new List<Session>();
                foreach (Session x in session_list) {
                    if (x.pasport_num == Convert.ToInt32(passport)) {
                        search_list.Add(x);
                    }
                }
                if (search_list.Count != 0) {
                    lab_info.Content = Extras.Time()+ "Информация по номеру паспорта " + passport;
                    main_grid.ItemsSource = search_list;
                }
                else { 
                    lab_info.Content = Extras.Time()+ "Информация по номеру паспорта " + passport + " не обнаружена";
                }

c Linq

Кликните здесь для просмотра всего текста

C#

                var linq_pass = from x in session_list
                    where x.pasport_num == Convert.ToInt32(passport)
                    select x;
                if (linq_pass.Count() != 0) {
                    lab_info.Content = Extras.Time()+ "Информация по номеру паспорта " + passport;
                    main_grid.ItemsSource = linq_pass;
                }
                else { 
                    lab_info.Content = Extras.Time()+ "Информация по номеру паспорта " + passport + " не обнаружена";
                }

Собственно что то мне подсказывает что в моем примере запрос выполняется дважды

1. if (linq_pass.Count() != 0)
2. main_grid.ItemsSource = linq_pass;

т.к linq_pass.Count() функция, а в первом примере search_list.Count - значение. Может действительно в данном случае использовать Linq не имеет смысла?

Добавлено через 6 минут
ну и вообще в каком случае будет лучше производительность?

@Hsert · 12.12.2013, 13:29

Count() - вызывает запрос Linq.
Linq создан, что комфорта программирования. Времена Pentium II уже давно прошли, современный компьютер способен справиться с почти всеми типичными задачами (по мощности), проблема производительности все больше перестает быть узким местом, для львинной доли задач (точнее уже давно перестала ) - взамен, удобство, скорость разработки, а главное читаемость кода , -становятся приоритетными.
С подобными мыслями я встречал только параноиков на C++.

@5665tm · 12.12.2013, 13:31 **[ТС]**

замерил и то и то через Stopwatch.ElapsedTicks разницы особо не увидел)

@ITL · 12.12.2013, 13:36

5665tm, прогони тот и тот вариант через цикл в миллион итерации и сравни общее время)

@5665tm · 12.12.2013, 14:42 **[ТС]**

Сообщение от ITL

5665tm, прогони тот и тот вариант через цикл в миллион итерации и сравни общее время)

лол, не думаю что кто то будет миллион раз искать инфу по паспорту

Сообщение от Hsert

проблема производительности все больше перестает быть узким местом

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

@ITL · 12.12.2013, 14:45

Сообщение от 5665tm

лол, не думаю что кто то будет миллион раз искать инфу по паспорту

Сообщение от 5665tm

Как бы там ни было, при сотне записей Linq оказался даже в среднем в два-три раза быстрее, чем без него, причем последующие поиски выполняются гораздо быстрее чем первый, видимо происходит нечто вроде кеширования.

Йод...именно для этого я и сказал посмотреть результаты. А не запихивать миллионы операций в конечный продукт.

@5665tm · 12.12.2013, 15:05 **[ТС]**

ITL, ну эмм... миллион раз найти одно значение среди 20 записей и один раз найти значение среди миллиона записей ведь разные вещи, разве нет? грубо говоря это как миллион раз написать Hello World и один раз написать ось в моем понимании. Не вижу смысла миллион раз искать одно и тоже, результат предсказуем, нужно всего лишь 70 000 (результат для одного поиска) умножить на 1 000 000. А вот при поиске среди разного количества значений насколько я помню время зависит нелинейно.

Во всяком случае при увеличении количества записей в 10 раз, время поиска увеличилось всего на 10-20%. Замерял именно время поиска без всяких выводов в label и data grid, так что все точно

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

@Hsert · 12.12.2013, 15:17

Сообщение от 5665tm

лол, не думаю что кто то будет миллион раз искать инфу по паспорту

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

"А если записей несколько тысяч" , "а если записей миллионы", "а если миллиарды"- это и называется паранойя.
Обычно условия задачи известны заранее и достаточно мало задач имеющих миллионы или миллиарды записей, как я уже говорил, для 99,99% решаемых задач, результат работы будет незаметен, для пользователя.

@Grishaco · 12.12.2013, 16:31

Сообщение от Hsert

Обычно условия задачи известны заранее и достаточно мало задач имеющих миллионы или миллиарды записей, как я уже говорил, для 99,99% решаемых задач, результат работы будет незаметен, для пользователя.

Да они известны заранее, есть заказчик, он говорит у меня 10000 договоров, вы делаете программу, а потом появляется еще один и у него уже 1000000 договоров, а с договорами связаны счета фактур и другие документы. И вот тут вы поймаете что нужно срочно переписывать, а то все тормозит.

Сообщение от Hsert

Времена Pentium II уже давно прошли, современный компьютер способен справиться с почти всеми типичными задачами (по мощности), проблема производительности все больше перестает быть узким местом, для львинной доли задач (точнее уже давно перестала ) - взамен, удобство, скорость разработки, а главное читаемость кода , -становятся приоритетными.

Я видел код на ling с пару страниц в VS, так вот i7 не справлялся (за приемлемое время), пришлось переписывать.

@Hsert · 12.12.2013, 17:07

Сообщение от Grishaco

Я видел код на ling с пару страниц в VS, так вот i7 не справлялся (за приемлемое время), пришлось переписывать.

Сообщение от Grishaco

Да они известны заранее, есть заказчик, он говорит у меня 10000 договоров, вы делаете программу, а потом появляется еще один и у него уже 1000000 договоров, а с договорами связаны счета фактур и другие документы. И вот тут вы поймаете что нужно срочно переписывать, а то все тормозит.

Такие задачи не зависят от языка, причем тут C#. В Linq есть Linq asParallel(),который распределяет всю нагрузку между всеми процессорами. Итого, что можно получить на C# за 1 минуту будет реализовано на с++ например за 2 часа, с плясками и бубнами, да еще и криво.

Хотел заметить, что далеко не все приложения, что тормозят написаны на C# с Linq , как раз таки многие написаны не сверх быстром, как тебе кажется C++, такими же как ты "борцами за быстродействие", которые своими кривыми руками не могут сделать ничего стоящего, оперируя языком 80х годов.

C# при запуске компилирует проект из IL в родной код, и кэширует его на диске, потом лишь запуская уже его кеш версию, в виде родного кода, но C# при генерации родного кода учитывает специфику компьютера и его процессор и оптимизирует его, что стандартному компилятору С++ не доступно.

Мы всегда придумывали миллионы, операций, когда был Pentium II, но сейчас компьютеры куда лучше и мы забыли про миллионы, а уже говорим про миллиарды, будет новое поколение компьютеров - будем снова говорить , но уже про Квадриллионы , - это не паранойя?? товарищ

Но % задач, при этом которые упираются в производительность, все меньше и меньше, например 1 задача из 1000, но всегда будут параноики , которые будут равняться на эту 0,001 % часть задач, и игнорировать остальные 99,999% всех задач.

Добавлено через 5 минут
.....
И не надо на меня выплескивать агрессию, ваше дело - идите в с++ там пишите велосипеды, с плясками и танцами.
Я лишь написал свое мнение, если вас оно не устраивает мне все равно.

@Grishaco · 12.12.2013, 17:15

Сообщение от Hsert

Но % задач, при этом которые упираются в производительность, все меньше и меньше, например 1 задача из 1000, но всегда будут параноики , которые будут равняться на эту 0,001 % часть задач, и игнорировать остальные 99,999% всех задач.

Да ладно, может наоборот 99% задач как раз критичны к производительности.

Вот простой пример, лик запрос отрабатывает в 6 раз медленнее при 100000.

C#

public class Test
    {
        public double X { get; set; }
        public double Y { get; set; }
 
        public double Result
        {
            get { return Math.Sqrt(X * Y * 100) + Math.Sqrt(X * Y * 100); }
        }
    }
 
private static void Main(string[] args)
        {
            var tests = new List<Test>();
            var r = new Random();
            for (int i = 0; i < 100000; i++)
            {
                tests.Add(new Test { X = r.NextDouble(), Y = r.NextDouble() });
            }
 
            Stopwatch s = new Stopwatch();
            s.Start();
            var enumerable = tests.Select(x => x.Result > 0.1 && x.Result < 0.3 || x.Result > 0.6 && x.Result < 0.8).ToList();
            s.Stop();
            Console.WriteLine(s.ElapsedMilliseconds);
            s.Reset();
            s.Start();
            var resultList = new List<Test>();
            foreach (var test in tests)
            {
                var result = test.Result;
                if (result > 0.1 && result < 0.3 || result > 0.6 && result < 0.8)
                {
                    resultList .Add(test);
                }
            }
            s.Stop();
            Console.WriteLine(s.ElapsedMilliseconds);
Console.ReadKey();
}

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

Сообщение от Hsert

И не надо на меня выплескивать агрессию, ваше дело - идите в с++ там пишите велосипеды, с плясками и танцами.
Я лишь написал свое мнение, если вас оно не устраивает мне все равно.

Какая агрессия вы о чем, я тоже высказал свое мнение.

@tezaurismosis · 12.12.2013, 18:47

Сообщение от 5665tm

Не вижу смысла миллион раз искать одно и тоже, результат предсказуем, нужно всего лишь 70 000 (результат для одного поиска) умножить на 1 000 000. А вот при поиске среди разного количества значений насколько я помню время зависит нелинейно.

Это зависит от сложности вашего алгоритма, если она O(n) - то время растёт линейно: 1 за 1 сек, 1000 за 1000 сек, а если другая, например O(n²) - то для 1000 будет уже 1000² = 10⁶ сек

Не по теме:

Сообщение от Hsert

С подобными мыслями я встречал только параноиков на C++

Прошу вас быть аккуратнее в выражениях.

@5665tm · 12.12.2013, 18:59 **[ТС]**

Сообщение от tezaurismosis

Это зависит от сложности вашего алгоритма

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

Добавлено через 1 минуту

Сообщение от Hsert

99,99% решаемых задач, результат работы будет незаметен, для пользователя.

Сообщение от 5665tm

и глядя на тормоза некоторых приложений при достаточно банальных операциях я что то не ощущаю что будущее наступило

Где то тут в соседней темке один товарищ жаловался что его цикл выполняется 12 секунд. Пустяки, можно же подождать.

@Hsert · 12.12.2013, 22:16

Сообщение от 5665tm

5665tm

Вы так и не поняли, 6 mc или 60 mc, какая разница для человека?, зато в 10! раз медленнее. И таких задач 99% , в которых пользователь не заметит разницы в работе. В крайнем случае, в C# есть масса прекрасных инструментов для распараллеливания кода.

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

Часто в задачах вы делаете циклы по 1000 000 или по 10 000 000 итераций? Я например вообще не помню когда писал последний раз цикл хотя бы в 100 000 итераций, кроме как для учебных примеров.

Не хотел никого обидеть.

@Grishaco · 12.12.2013, 22:39

Сообщение от Hsert

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

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

Да и еще кто нибудь может показать, как сами товарищи из Microsoft используют Linq в разработке NET Framework?

Добавлено через 5 минут

Сообщение от Hsert

Часто в задачах вы делаете циклы по 1000 000 или по 10 000 000 итераций? Я например вообще не помню когда писал последний раз цикл хотя бы в 100 000 итераций, кроме как для учебных примеров.

Наверное вы не писали системы оптимизации работы оборудования.

@Hsert · 12.12.2013, 22:43

Мое мнение думаю уже предельно понятно.
Делайте как считаете нужным.

@5665tm · 12.12.2013, 22:47 **[ТС]**

Hsert, я не спорю с тем что можно пренебречь некоторой долей производительности для улучшения сопровождения приложения, здесь вы правы на 100% Но когда дело доходит до того что на двухядерном планшете я не могу просто плавно листать страницы в браузере мне действительно становится не очень комфортно скажем так

@Hsert 10 / 25 / 9 Регистрация: 08.12.2013 Сообщений: 115
	12.12.2013, 13:29	2
	Count() - вызывает запрос Linq. Linq создан, что комфорта программирования. Времена Pentium II уже давно прошли, современный компьютер способен справиться с почти всеми типичными задачами (по мощности), проблема производительности все больше перестает быть узким местом, для львинной доли задач (точнее уже давно перестала ) - взамен, удобство, скорость разработки, а главное читаемость кода , -становятся приоритетными. С подобными мыслями я встречал только параноиков на C++. 0

@5665tm 171 / 120 / 14 Регистрация: 17.06.2013 Сообщений: 386
	12.12.2013, 13:31 [ТС]	3
	замерил и то и то через Stopwatch.ElapsedTicks разницы особо не увидел) 0

@ITL 284 / 255 / 73 Регистрация: 17.07.2012 Сообщений: 618
	12.12.2013, 13:36	4
	5665tm, прогони тот и тот вариант через цикл в миллион итерации и сравни общее время) 0

@5665tm 171 / 120 / 14 Регистрация: 17.06.2013 Сообщений: 386
	12.12.2013, 14:42 [ТС]	5
	Сообщение от ITL 5665tm, прогони тот и тот вариант через цикл в миллион итерации и сравни общее время) лол, не думаю что кто то будет миллион раз искать инфу по паспорту Сообщение от Hsert проблема производительности все больше перестает быть узким местом так то оно так, но возможности то не безграничны, а что если записей несколько тысяч? и глядя на тормоза некоторых приложений при достаточно банальных операциях я что то не ощущаю что будущее наступило. Как бы там ни было, при сотне записей Linq оказался даже в среднем в два-три раза быстрее, чем без него, причем последующие поиски выполняются гораздо быстрее чем первый, видимо происходит нечто вроде кеширования. 0

@ITL 284 / 255 / 73 Регистрация: 17.07.2012 Сообщений: 618
	12.12.2013, 14:45	6
	Сообщение от 5665tm лол, не думаю что кто то будет миллион раз искать инфу по паспорту Сообщение от 5665tm Как бы там ни было, при сотне записей Linq оказался даже в среднем в два-три раза быстрее, чем без него, причем последующие поиски выполняются гораздо быстрее чем первый, видимо происходит нечто вроде кеширования. Йод...именно для этого я и сказал посмотреть результаты. А не запихивать миллионы операций в конечный продукт. 0

@5665tm 171 / 120 / 14 Регистрация: 17.06.2013 Сообщений: 386
	12.12.2013, 15:05 [ТС]	7
	ITL, ну эмм... миллион раз найти одно значение среди 20 записей и один раз найти значение среди миллиона записей ведь разные вещи, разве нет? грубо говоря это как миллион раз написать Hello World и один раз написать ось в моем понимании. Не вижу смысла миллион раз искать одно и тоже, результат предсказуем, нужно всего лишь 70 000 (результат для одного поиска) умножить на 1 000 000. А вот при поиске среди разного количества значений насколько я помню время зависит нелинейно. Во всяком случае при увеличении количества записей в 10 раз, время поиска увеличилось всего на 10-20%. Замерял именно время поиска без всяких выводов в label и data grid, так что все точно Добавлено через 4 минуты А хотя нет, криво я замерял, вывод попадал, недоглядел, так что я неправ во многих своих высказываниях выше, в общем в топку этот спор, я действительно сильно заморочился) как оказалось время поиска пренебрежительно мало по сравнению с временем выводом результатов на экран. 0

@Hsert 10 / 25 / 9 Регистрация: 08.12.2013 Сообщений: 115
	12.12.2013, 15:17	8
	Сообщение от 5665tm лол, не думаю что кто то будет миллион раз искать инфу по паспорту так то оно так, но возможности то не безграничны, а что если записей несколько тысяч? и глядя на тормоза некоторых приложений при достаточно банальных операциях я что то не ощущаю что будущее наступило. Как бы там ни было, при сотне записей Linq оказался даже в среднем в два-три раза быстрее, чем без него, причем последующие поиски выполняются гораздо быстрее чем первый, видимо происходит нечто вроде кеширования. "А если записей несколько тысяч" , "а если записей миллионы", "а если миллиарды"- это и называется паранойя. Обычно условия задачи известны заранее и достаточно мало задач имеющих миллионы или миллиарды записей, как я уже говорил, для 99,99% решаемых задач, результат работы будет незаметен, для пользователя. 0

@Grishaco 438 / 362 / 100 Регистрация: 29.06.2010 Сообщений: 981 Записей в блоге: 1
	12.12.2013, 16:31	9
	Сообщение от Hsert Обычно условия задачи известны заранее и достаточно мало задач имеющих миллионы или миллиарды записей, как я уже говорил, для 99,99% решаемых задач, результат работы будет незаметен, для пользователя. Да они известны заранее, есть заказчик, он говорит у меня 10000 договоров, вы делаете программу, а потом появляется еще один и у него уже 1000000 договоров, а с договорами связаны счета фактур и другие документы. И вот тут вы поймаете что нужно срочно переписывать, а то все тормозит. Сообщение от Hsert Времена Pentium II уже давно прошли, современный компьютер способен справиться с почти всеми типичными задачами (по мощности), проблема производительности все больше перестает быть узким местом, для львинной доли задач (точнее уже давно перестала ) - взамен, удобство, скорость разработки, а главное читаемость кода , -становятся приоритетными. Я видел код на ling с пару страниц в VS, так вот i7 не справлялся (за приемлемое время), пришлось переписывать. 0

@Hsert 10 / 25 / 9 Регистрация: 08.12.2013 Сообщений: 115
	12.12.2013, 17:07	10
	Сообщение от Grishaco Я видел код на ling с пару страниц в VS, так вот i7 не справлялся (за приемлемое время), пришлось переписывать. Сообщение от Grishaco Да они известны заранее, есть заказчик, он говорит у меня 10000 договоров, вы делаете программу, а потом появляется еще один и у него уже 1000000 договоров, а с договорами связаны счета фактур и другие документы. И вот тут вы поймаете что нужно срочно переписывать, а то все тормозит. Такие задачи не зависят от языка, причем тут C#. В Linq есть Linq asParallel(),который распределяет всю нагрузку между всеми процессорами. Итого, что можно получить на C# за 1 минуту будет реализовано на с++ например за 2 часа, с плясками и бубнами, да еще и криво. Хотел заметить, что далеко не все приложения, что тормозят написаны на C# с Linq , как раз таки многие написаны не сверх быстром, как тебе кажется C++, такими же как ты "борцами за быстродействие", которые своими кривыми руками не могут сделать ничего стоящего, оперируя языком 80х годов. C# при запуске компилирует проект из IL в родной код, и кэширует его на диске, потом лишь запуская уже его кеш версию, в виде родного кода, но C# при генерации родного кода учитывает специфику компьютера и его процессор и оптимизирует его, что стандартному компилятору С++ не доступно. Мы всегда придумывали миллионы, операций, когда был Pentium II, но сейчас компьютеры куда лучше и мы забыли про миллионы, а уже говорим про миллиарды, будет новое поколение компьютеров - будем снова говорить , но уже про Квадриллионы , - это не паранойя?? товарищ Но % задач, при этом которые упираются в производительность, все меньше и меньше, например 1 задача из 1000, но всегда будут параноики , которые будут равняться на эту 0,001 % часть задач, и игнорировать остальные 99,999% всех задач. Добавлено через 5 минут ..... И не надо на меня выплескивать агрессию, ваше дело - идите в с++ там пишите велосипеды, с плясками и танцами. Я лишь написал свое мнение, если вас оно не устраивает мне все равно. 1

@tezaurismosis Администратор 9602 / 4744 / 761 Регистрация: 17.04.2012 Сообщений: 9,592 Записей в блоге: 14
	12.12.2013, 18:47	12
	Сообщение от 5665tm Не вижу смысла миллион раз искать одно и тоже, результат предсказуем, нужно всего лишь 70 000 (результат для одного поиска) умножить на 1 000 000. А вот при поиске среди разного количества значений насколько я помню время зависит нелинейно. Это зависит от сложности вашего алгоритма, если она O(n) - то время растёт линейно: 1 за 1 сек, 1000 за 1000 сек, а если другая, например O(n²) - то для 1000 будет уже 1000² = 10⁶ сек Не по теме: Сообщение от Hsert С подобными мыслями я встречал только параноиков на C++ Прошу вас быть аккуратнее в выражениях. 1

	12.12.2013, 22:47

@5665tm 171 / 120 / 14 Регистрация: 17.06.2013 Сообщений: 386
	12.12.2013, 18:59 [ТС]	13
	Сообщение от tezaurismosis Это зависит от сложности вашего алгоритма я это понимаю, что то такое в Кормене было) я имел в виду что не помню точно является ли, как бы это сказать, сложность алгоритма поиска записи в бд линейной. Добавлено через 1 минуту Сообщение от Hsert 99,99% решаемых задач, результат работы будет незаметен, для пользователя. Сообщение от 5665tm и глядя на тормоза некоторых приложений при достаточно банальных операциях я что то не ощущаю что будущее наступило Где то тут в соседней темке один товарищ жаловался что его цикл выполняется 12 секунд. Пустяки, можно же подождать. 0

@Hsert 10 / 25 / 9 Регистрация: 08.12.2013 Сообщений: 115
	12.12.2013, 22:16	14
	Сообщение от 5665tm 5665tm Вы так и не поняли, 6 mc или 60 mc, какая разница для человека?, зато в 10! раз медленнее. И таких задач 99% , в которых пользователь не заметит разницы в работе. В крайнем случае, в C# есть масса прекрасных инструментов для распараллеливания кода. Самый быстрый код, не всегда легко читаемый,компактный, аккуратный, а главное быстрый в разработке и способный к долгосрочному сопровождению разными программистами. Если исходить из этого, то так вообще лучше писать на ассемблере, не применяя никакого ООП, а смешивая все в зависимую друг от друга кучу, и такой код будет самый быстрый, но большие проекты ему не под силу, а за поддержку нужно вообще забыть. В наш век быстрота написания крупного объема кода и его поддержка становится чуть ли не ключевым фактором в выборе инструмента программирования, а производительность все больше перестает быть узким местом в программировании. Часто в задачах вы делаете циклы по 1000 000 или по 10 000 000 итераций? Я например вообще не помню когда писал последний раз цикл хотя бы в 100 000 итераций, кроме как для учебных примеров. Не хотел никого обидеть. 1

@Grishaco 438 / 362 / 100 Регистрация: 29.06.2010 Сообщений: 981 Записей в блоге: 1
	12.12.2013, 22:39	15
	Сообщение от Hsert Самый быстрый код, не всегда легко читаемый,компактный, аккуратный, а главное быстрый в разработке и способный к долгосрочному сопровождению разными программистами. Если исходить из этого, то так вообще лучше писать на ассемблере, не применяя никакого ООП, а смешивая все в зависимую друг от друга кучу, и такой код будет самый быстрый, но большие проекты ему не под силу, а за поддержку нужно вообще забыть К сожалению, последнее время я вижу другую тенденцию. Да и еще кто нибудь может показать, как сами товарищи из Microsoft используют Linq в разработке NET Framework? Добавлено через 5 минут Сообщение от Hsert Часто в задачах вы делаете циклы по 1000 000 или по 10 000 000 итераций? Я например вообще не помню когда писал последний раз цикл хотя бы в 100 000 итераций, кроме как для учебных примеров. Наверное вы не писали системы оптимизации работы оборудования. 0

@Hsert 10 / 25 / 9 Регистрация: 08.12.2013 Сообщений: 115
	12.12.2013, 22:43	16
	Мое мнение думаю уже предельно понятно. Делайте как считаете нужным. 0

@5665tm 171 / 120 / 14 Регистрация: 17.06.2013 Сообщений: 386
	12.12.2013, 22:47 [ТС]	17
	Hsert, я не спорю с тем что можно пренебречь некоторой долей производительности для улучшения сопровождения приложения, здесь вы правы на 100% Но когда дело доходит до того что на двухядерном планшете я не могу просто плавно листать страницы в браузере мне действительно становится не очень комфортно скажем так 0