¿SoCaseInsensitive tiene un gran impacto en el rendimiento de un TdxMemIndex en un TdxMemDataset?

Question

Estoy agregando algunos índices a mi DevExpress TdxMemDataset para mejorar el rendimiento. El TdxMemIndex tiene SortOptions que incluyen la opción para soCaseInsensitive . Mis datos suelen ser una cadena GUID, por lo que no distinguen entre mayúsculas y minúsculas. Me pregunto si es mejor forzar todos los datos al mismo caso o si el indicador soCaseInsensitive y usar el indicador loCaseInsensitive con la llamada a Localizar tiene solo un menor penalización de rendimiento (aproximadamente igual a convertir el caso de mi cadena cada vez que necesito usar el índice).

En este punto, estoy dejando el CaseInsentive desactivado y simplemente convirtiendo el caso.

Answer 1

En mi humilde opinión, lo mejor es asegurar la calidad de los datos en el momento de la publicación. Razonamientos:

1. Usted (generalmente) conoce la naturaleza de los datos. Entonces, por ejemplo. puede usar UpperCase (sabiendo que los GUID están todos en el rango ASCII) en lugar de mucho un AnsiUpperCase más lento que un componente general como TdxMemDataSet está obligado a usar.

2. Usted ingresa los datos solo una vez. Buscar / Ordenar / Filtrar, lo que implica que el motor de superposición interna de TdxMemDataSet es una acción repetida. Además, hay otras acciones encadenadas que activarán este motor sin darse cuenta. (Por ejemplo, un TcxGrid que está ordenado de forma predeterminada con GridMode: = True (supongo que usa los componentes DevEx.) Y una clase que actúa como un intermediario que pasa el mensaje de clasificación al conjunto de datos subyacente.

3. Por lo general, la entrada de datos se realiza en pasos, uno o pocos registros en un lote. La única excepción notable son las aplicaciones de adquisición de datos. Pero en los dos casos anteriores, la cultura de usabilidad del usuario permite manera mayores tiempos de respuesta para que juegues. (¿AHORA cuánto agregaría una llamada de UpperCase a una publicación de registro que dura 0.005 ms?) OTOH, los usuarios son muy exigentes con la velocidad de las operaciones de recuperación de datos (búsqueda, clasificación, filtrado, etc.). Mantenga la recuperación de datos tan rápido como pueda.

4. Tener los datos en la base de datos listos para exponer reduce el riesgo de errores de procesamiento cuando escribes ( si escribirás) otros módulos (debes recordar a AnsiUpperCase el datos en cualquier módulo en cualquier idioma que escriba). También aquí, un ejemplo clásico es cuando usará otras herramientas externas para acceder a los datos (por ejemplo, los administradores de db para ejecutar un SQL SELCT sobre los datos).

hth.

Answer 2

Tal vez los foros DevExpress (o alguna vez un correo electrónico de soporte, si tiene acceso a él) serían un mejor lugar para buscar una respuesta autorizada sobre esa pregunta de rendimiento.

De todos modos, es mejor garantizar que los datos estén en el formato que desee, por las razones que ya explicamos, en el momento en que los guarde. Entonces, en ese específico, asegúrese de que el GUID esté escrito en mayúscula (o inferior, es cuestión de gustos). Si es SQL Server u otro servidor de base de datos que tiene un tipo de datos guid, asegúrese de que SELECT haga el trabajo, si es aplicable y posible , incluso el tipo.