Linq to SharePoint. Сравнение производительности с Camlex.NET

11 марта, 2012

Часть 1. First()/FirstOrDefault(), T-SQL IN, Path
Часть 2. Count(), Take(), Skip(), JOIN
Часть 3. Анонимный доступ, Получение списка по URL'у, Cross-Site запросы
Часть 4. SPListItem -> LINQ, Dynamic Linq to SharePoint
Часть 5. Поля Choice и MultiChoice в Linq to SharePoint
Часть 6. Сравнение производительности Linq to SharePoint и Camlex.NET

Еще один пост, посвященный работе с Linq to SharePoint. На этот раз я решил измерить скорость работы с данными и сравнить производительность Linq to SharePoint и Camlex.NET.

Получение данных из списка

Для измерения производительности я опять же использовал модель данных из второй части постов, посвященных Linq to SharePoint. Время, потраченное на выборку я измерял с помощью класса System.Diagnostics.Stopwatch. Саму выборку проводил несколько раз как при "холодном" старте, так и при "горячем". Запросы были максимально сложными и идентичными (насколько это возможно). JOIN'ы я использовал только для того, чтобы иметь возможность отфильтровать данные по LookupValue. Не думаю, что это сильно отразится на результатах (Camlex.NET, не умеет строить JOIN'ы). Предварительно я сгенерировал 20 тысяч записей в списке Employees.

И так, запрос, который был передан Linq to SharePoint:



using (var ctx = new ZhukDataContext(siteUrl))
{
    var exEmpIds = new int?[] { 1, 2, 3, 4, 5 };
    var query = ctx.Employees
        .ScopeToFolder(string.Empty, true)
        .Where(emp => emp.SexValue == "Male")
        .Where(emp => emp.Title.Contains("Jr."))
        .Where(emp => emp.Department.Title != "IT")
        .Where(Extensions.NotEqualsAll<Employee, int?>(i => i.Id, exEmpIds))
        .OrderBy(emp => emp.Title)
        .Take(100);
    var items = query.ToList();
}

Немного пояснений:

exEmpIds - массив Id сотрудников, которые должны быть исключены;
SexValue - поле типа "выбор" (choice);
Title.Contains - вызов метода Contains в CAML-запросе;
Department.Title - фильтрация по LookupValue;

Аналогичный запрос в Camlex.NET будет выглядеть менее изящно:



using (var site = new SPSite(siteUrl))
{
    using (var web = site.OpenWeb())
    {
        var list = web.Lists["Employees"];
        var expressions = new List<Expression<Func<SPListItem, bool>>>();
        expressions.Add(x => (string) x["Sex"] == "Male");
        expressions.Add(x => ((string) x["Title"]).Contains("Jr."));
        expressions.Add(x => x["Department"] != (DataTypes.LookupValue) "IT");
        foreach (var empId in exEmpIds)
        {
            int id = empId.Value;
            expressions.Add(x => (int) x["ID"] != id);
        }
        var caml = Camlex.Query()
            .WhereAll(expressions)
            .OrderBy(x => x["Title"]);
        var query = new SPQuery
                        {
                            RowLimit = 100,
                            Query = caml.ToString()
                        };
        var items = list.GetItems(query)
            .Cast<SPListItem>()
            .ToList();
 
    }
}

Для начала необходимо посмотреть CAML-запросы, которые будут сгенерированы для получения элементов списка. Сначала Linq to SharePoint:



<View Scope='RecursiveAll'>
  <Query>
    <Where>
      <And>
        <And>
          <And>
            <And>
              <BeginsWith>
                <FieldRef Name="ContentTypeId" />
                <Value Type="ContentTypeId">0x010078B0DD38574940478CF9E129FCD65E9B</Value>
              </BeginsWith>
              <Eq>
                <FieldRef Name="Sex" />
                <Value Type="Choice">Male</Value>
              </Eq>
            </And>
            <Contains>
              <FieldRef Name="Title" />
              <Value Type="Text">Jr.</Value>
            </Contains>
          </And>
          <Neq>
            <FieldRef Name="DepartmentTitle" />
            <Value Type="Lookup">IT</Value>
          </Neq>
        </And>
        <And>
          <And>
            <And>
              <And>
                <Neq>
                  <FieldRef Name="ID" />
                  <Value Type="Counter">1</Value>
                </Neq>
                <Neq>
                  <FieldRef Name="ID" />
                  <Value Type="Counter">2</Value>
                </Neq>
              </And>
              <Neq>
                <FieldRef Name="ID" />
                <Value Type="Counter">3</Value>
              </Neq>
            </And>
            <Neq>
              <FieldRef Name="ID" />
              <Value Type="Counter">4</Value>
            </Neq>
          </And>
          <Neq>
            <FieldRef Name="ID" />
            <Value Type="Counter">5</Value>
          </Neq>
        </And>
      </And>
    </Where>
    <OrderBy Override="TRUE">
      <FieldRef Name="Title" />
    </OrderBy>
  </Query>
  <ViewFields>
    <FieldRef Name="Sex" />
    <FieldRef Name="CellPhone" />
    <FieldRef Name="AccessLevel" />
    <FieldRef Name="Manager" />
    <FieldRef Name="Department" />
    <FieldRef Name="ID" />
    <FieldRef Name="owshiddenversion" />
    <FieldRef Name="FileDirRef" />
    <FieldRef Name="Title" />
    <FieldRef Name="Author" />
    <FieldRef Name="Editor" />
  </ViewFields>
  <ProjectedFields>
    <Field Name="DepartmentTitle" Type="Lookup" List="Department" ShowField="Title" />
  </ProjectedFields>
  <Joins>
    <Join Type="LEFT" ListAlias="Department">
      <!--List Name: Departments-->
      <Eq>
        <FieldRef Name="Department" RefType="ID" />
        <FieldRef List="Department" Name="ID" />
      </Eq>
    </Join>
  </Joins>
  <RowLimit Paged="TRUE">100</RowLimit>
</View>

Здесь все правильно. Теперь очередь Camlex.NET:



<Where>
  <And>
    <And>
      <And>
        <And>
          <And>
            <And>
              <And>
                <Eq>
                  <FieldRef Name="Sex" />
                  <Value Type="Text">Male</Value>
                </Eq>
                <Contains>
                  <FieldRef Name="Title" />
                  <Value Type="Text">Jr.</Value>
                </Contains>
              </And>
              <Neq>
                <FieldRef Name="Department" />
                <Value Type="Lookup">IT</Value>
              </Neq>
            </And>
            <Neq>
              <FieldRef Name="ID" />
              <Value Type="Integer">5</Value>
            </Neq>
          </And>
          <Neq>
            <FieldRef Name="ID" />
            <Value Type="Integer">4</Value>
          </Neq>
        </And>
        <Neq>
          <FieldRef Name="ID" />
          <Value Type="Integer">3</Value>
        </Neq>
      </And>
      <Neq>
        <FieldRef Name="ID" />
        <Value Type="Integer">2</Value>
      </Neq>
    </And>
    <Neq>
      <FieldRef Name="ID" />
      <Value Type="Integer">1</Value>
    </Neq>
  </And>
</Where>

Тоже хорошо. Есть недочеты, но на скорость они не повлияют. Теперь осталось измерить скорость выбора данных. Вот мои результаты для "холодного" и "горячего" стартов соответственно:

На "холодном" старте разница невелика, т.к. в обоих случаях происходит инициализация объектов SPSite, SPWeb, SPList и других. На "горячем" старте, когда объекты закэшированы очевидно виден лидер - Linq to SharePoint.

Тест под нагрузкой

Дальше я измерял производительность Camlex.NET в двух режимах: просто выбор элементов из списка и минимальное преобразование SPlistItem в Employee (new Employee { Title = item["Title"] }). В первом случае я пытался добиться максимальной производительности, а во втором случае приблизил сценарий к реальной жизни. При этом я повышал количество выбираемых элементов, начиная с 10 и заканчивая 2500. Результаты производительности Camlex.NET под нагрузкой:

Производительность Camlex.NET в зависимости от нагрузки

Для Linq to SharePoint я придумал два других варианта работы. Первый в режиме ReadOnly (ObjectTrackingEnabled = false), второй - с включенным трекингом. Все остальные параметры были идентичны Camlex.NET. Результаты производительности Linq to SharePoint под нагрузкой:

Производительность Linq to SharePoint в зависимости от нагрузки

Если свести все вместе для удобства сравнения:

Производительность Camlex.NET и Linq to SharePoint в зависимости от нагрузки

Выводы

Выводы просты и очевидны: Linq to SharePoint не только работает быстрее, но и обладает большими возможностями по сравнению с Camlex.NET. Используя Linq to SharePoint мы получаем типизированную коллекцию, в случае с Camlex.NET коллекцию объектов SPListItem, которую ещё предстоит "замапить" на объекты.

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