Влияет ли soCaseInsensitive на производительность для TdxMemIndex в TdxMemDataset? - PullRequest
Новая
       40

Влияет ли soCaseInsensitive на производительность для TdxMemIndex в TdxMemDataset?

0 голосов
/ 16 марта 2009

Я добавляю несколько индексов в мой DevExpress TdxMemDataset для повышения производительности. TdxMemIndex имеет SortOptions , которые включают опцию для soCaseInsensitive . Мои данные обычно представляют собой строку GUID, поэтому они не чувствительны к регистру. Я задаюсь вопросом, лучше ли мне просто принудить все данные к одному и тому же случаю или если флаг soCaseInsensitive и использование флага loCaseInsensitive с вызовом Locate имеет лишь незначительное снижение производительности (примерно равно преобразованию регистра моей строки каждый раз, когда мне нужно использовать индекс).

На данный момент я отключаю CaseInsentive и просто конвертирую case.

Ответы [ 2 ]

8 голосов
/ 16 марта 2009

ИМХО, лучше всего обеспечить качество данных в пост-время. Рассуждения:

  1. Вы (обычно) знаете характер данных. Так, например. вы можете использовать UpperCase (зная, что все GUID находятся в диапазоне ASCII) вместо намного более медленного AnsiUpperCase, который вынужден использовать общий компонент, такой как TdxMemDataSet.

  2. Вы вводите данные только один раз. Поиск / Сортировка / Фильтрация, что подразумевает внутренний механизм обработки TdxMemDataSet, это повторяющееся действие. Кроме того, есть другие цепные действия, которые будут запускать этот двигатель без реализации. (Например, TcxGrid, который по умолчанию сортируется с GridMode: = True (я предполагаю, что вы используете компоненты DevEx.) И имеет класс, действующий как брокер, передающий сообщение сортировки в базовый набор данных.

  3. Обычно ввод данных выполняется поэтапно, одна или несколько записей в пакете. Единственным заметным исключением являются приложения для сбора данных. Но в обоих случаях выше культура юзабилити пользователя позволяет способ большее время отклика для вас играть. (Какова сумма добавления вызова UpperCase к записи записи, которая длится 0,005 мс?) OTOH, пользователи очень требовательны со скоростью операций извлечения данных (поиск, сортировка, фильтрация и т. Д.). Сохраняйте извлечение данных как можно быстрее.

  4. Наличие данных в базе данных, готовых к представлению, снижает риск ошибок обработки, когда вы будете писать (, если вы напишете) другие модули (вам необходимо запомнить AnsiUpperCase данные в любом модуле на любом языке напишешь). Также здесь классический пример, когда вы будете использовать другие внешние инструменты для доступа к данным (например, менеджеры БД для выполнения SQL SELCT над данными).

НТН.

1 голос
/ 16 марта 2009

Возможно, форумы DevExpress (или когда-нибудь письмо поддержки, если у вас есть к нему доступ) были бы лучшим местом для поиска авторитетного ответа на этот вопрос о производительности.

В любом случае, лучше всего гарантировать, что данные будут в нужном формате - по понятным причинам - в тот момент, когда вы их сохраните. Итак, в этом конкретном случае, убедитесь, что GUID написан в верхнем (или нижнем, дело вкуса). Если это SQL Server или другой сервер базы данных с типом данных guid, убедитесь, что SELECT работает - если применимо и возможно , даже сортировка.

...