Сообщение Re[91]: Тормознутость и кривость linq от 01.05.2016 5:58
Изменено 01.05.2016 12:49 Pauel
Здравствуйте, alex_public, Вы писали:
_>Ты совсем глупый или не умеешь читать? ) И 2-12 микросекунд и 12 миллисекунд — это накладные расходы (а не суммарное время), которые в принципе никак не зависят от времени исполнения самого запроса. Хоть там будет наносекунда, хоть час.
Я невнимательно прочел код, у тебя в замеры в одном месте попадает tr.commit
Ты перепахиваешь память и только по этому у тебя заметны издержки. Как только начинаешь работать уже с диском, то разницы, по твоим же словам, не видно никакой.
>разница явно где-то за пределами погрешности измерения. И только введение индекса (и соответственно приведение времени запроса к смешным значениям) позволило выявить реальный размер накладных расходов данной библиотечки
В кратце, это признание того, что на фоне обращения к базе твою оптимизацию в микроскоп не видно.
В реальной работе такого фокуса у тебя не будет, потому что уже сеть съест весь профит. Еще раз — ты перепахиваешь виртуальную память !
_>P.S. Ну и для общего образования: обращение к памяти — это наносекунды, у нас всё же не 90-ые. )))
Ты всё таки не можешь не удержаться, что бы не юродствовать. Типа ты не понял, что речь про _виртуальную_ _память_ и надо считать commit и дисковый io
_>Ты совсем глупый или не умеешь читать? ) И 2-12 микросекунд и 12 миллисекунд — это накладные расходы (а не суммарное время), которые в принципе никак не зависят от времени исполнения самого запроса. Хоть там будет наносекунда, хоть час.
Я невнимательно прочел код, у тебя в замеры в одном месте попадает tr.commit
Ты перепахиваешь память и только по этому у тебя заметны издержки. Как только начинаешь работать уже с диском, то разницы, по твоим же словам, не видно никакой.
>разница явно где-то за пределами погрешности измерения. И только введение индекса (и соответственно приведение времени запроса к смешным значениям) позволило выявить реальный размер накладных расходов данной библиотечки
В кратце, это признание того, что на фоне обращения к базе твою оптимизацию в микроскоп не видно.
В реальной работе такого фокуса у тебя не будет, потому что уже сеть съест весь профит. Еще раз — ты перепахиваешь виртуальную память !
_>P.S. Ну и для общего образования: обращение к памяти — это наносекунды, у нас всё же не 90-ые. )))
Ты всё таки не можешь не удержаться, что бы не юродствовать. Типа ты не понял, что речь про _виртуальную_ _память_ и надо считать commit и дисковый io
Re[91]: Тормознутость и кривость linq
Здравствуйте, alex_public, Вы писали:
_>Ты совсем глупый или не умеешь читать? ) И 2-12 микросекунд и 12 миллисекунд — это накладные расходы (а не суммарное время), которые в принципе никак не зависят от времени исполнения самого запроса. Хоть там будет наносекунда, хоть час.
Я невнимательно прочел код, у тебя в замеры в одном месте попадает tr.commit
Ты перепахиваешь память и только по этому у тебя заметны издержки. Как только начинаешь работать уже с диском, то разницы, по твоим же словам, не видно никакой.
>разница явно где-то за пределами погрешности измерения. И только введение индекса (и соответственно приведение времени запроса к смешным значениям) позволило выявить реальный размер накладных расходов данной библиотечки
В кратце, это признание того, что на фоне обращения к базе твою оптимизацию в микроскоп не видно.
В реальной работе такого фокуса у тебя не будет, потому что уже сеть съест весь профит. Еще раз — ты перепахиваешь виртуальную память !
_>P.S. Ну и для общего образования: обращение к памяти — это наносекунды, у нас всё же не 90-ые. )))
Ты всё таки не можешь удержаться, что бы не юродствовать. Типа ты не понял, что речь про _виртуальную_ _память_ и надо считать commit и дисковый io
_>Ты совсем глупый или не умеешь читать? ) И 2-12 микросекунд и 12 миллисекунд — это накладные расходы (а не суммарное время), которые в принципе никак не зависят от времени исполнения самого запроса. Хоть там будет наносекунда, хоть час.
Я невнимательно прочел код, у тебя в замеры в одном месте попадает tr.commit
Ты перепахиваешь память и только по этому у тебя заметны издержки. Как только начинаешь работать уже с диском, то разницы, по твоим же словам, не видно никакой.
>разница явно где-то за пределами погрешности измерения. И только введение индекса (и соответственно приведение времени запроса к смешным значениям) позволило выявить реальный размер накладных расходов данной библиотечки
В кратце, это признание того, что на фоне обращения к базе твою оптимизацию в микроскоп не видно.
В реальной работе такого фокуса у тебя не будет, потому что уже сеть съест весь профит. Еще раз — ты перепахиваешь виртуальную память !
_>P.S. Ну и для общего образования: обращение к памяти — это наносекунды, у нас всё же не 90-ые. )))
Ты всё таки не можешь удержаться, что бы не юродствовать. Типа ты не понял, что речь про _виртуальную_ _память_ и надо считать commit и дисковый io