Для начала, несколько оговорок и комментариев. Во-первых, процесс оценки производительности сложен. Трудно выполнять измерения. Но настоящая проблема состоит в том, что часто мы забываем, ДЛЯ ЧЕГО мы оцениваем производительность чего-либо. Мы берем сложную многомашинную финансовую систему и внезапно чрезвычайно фокусируемся на куске кода, выполняющем сериализацию, который, по нашему убеждению, и ЕСТЬ проблема. «Если я смогу оптимизировать эту сериализацию, написав for-цикл из 10000 итерации и сократив время его выполнения на x миллисекунд, все будет путем».
Средства LINQ позволяют .Net-разработчикам единообразно работать как с коллекциями объектов в памяти, так и с объектами, хранящимися в базе данных или ином удаленном источнике. Например, для запроса десяти красных яблок из списка в памяти и из БД средствами Entity Framework мы можем использовать абсолютно идентичный код:
List<Apple> appleList;
DbSet<Apple> appleDbSet;
var applesFromList = appleList.Where(apple => apple.Color == “red”).Take(10);
var applesFromDb = appleDbSet.Where(apple => apple.Color == “red”).Take(10);
Однако, выполняются эти запросы по-разному. В первом случае при перечислении результата с помощью foreach яблоки будут отфильтрованы с помощью заданного предиката, после чего будут взяты первые 10 из них. Во втором случае синтаксическое дерево с выражением запроса будет передано специальному LINQ-провайдеру, который транслирует его в SQL-запрос к базе данных и выполнит, после чего сформирует для 10 найденных записей объекты С# и вернет их. Обеспечить такое поведение позволяет интерфейс IQueryable<T>, предназначенный для создания LINQ-провайдеров к внешним источникам данных. Ниже мы попробуем разобраться с принципами организации и использования этого интерфейса.
Уважаемые читатели! Представляю вашему вниманию перевод статьи Скота Ханселмана под названием "Proper benchmarking to diagnose and solve a .NET serialization bottleneck".