Profiling de Listados

Creado por Pablo Céspedes, Modificado el Mie, 15 Abr a 3:08 P. M. por Pablo Céspedes

Activación

Para obtener datos de rendimiento de los listados, debe tener activa la opción "SQL Trace activo", disponible para cualquier administrador pulsando en la cabecera de un formulario el botón derecho. A continuación, genere el listado normalmente.

A partir de este momento se guardarán las métricas y los pasos por los que transcurre la carga, con información ampliada, para los listados de tipo DevExpress. Existe una funcionalidad muy limitada que mide tiempos de forma básica en Crystal Reports, pero no aplica la mayoría de información del siguiente documento.

Para consultar la información, abra el SQL Tracer y asegúrese de que los filtros ListadoPaso y ListadoResumen estén marcados (checkboxes en la parte superior derecha del formulario).

Columnas del grid

Columna	Contenido
Nº	Número secuencial de la traza. Le permite ordenar cronológicamente.
Fecha	Fecha y hora del evento (formato corto con HH:MM).
Tiempo	Duración en segundos con 3 decimales (ej: `0,167` = 167 ms). Para las líneas de tipo ListadoResumen, indica el tiempo total del listado completo.
Tipo	`ListadoPaso` para cada fase individual, `ListadoResumen` para el total final.
Descrip	Texto descriptivo del paso. Estructura: `[Motor] Fichero.repx - NombrePaso: X ms (Y s)`.
Detalles	Pulse el botón en esta columna para ampliar información.

Cómo leer la columna Descrip

El prefijo entre corchetes indica el motor y la operación:

[DX-E]: DevExpress — Exportación directa (a PDF, Excel, etc.)
[DX-P]: DevExpress — Vista previa en pantalla
[CR-E]: Crystal Reports — Exportación
[CR-P]: Crystal Reports — Vista previa

Pasos principales (secuenciales)

Paso	Qué mide
XtraReport.FromFile	Carga del fichero .repx desde disco a memoria.
FlexybilizaReportCompleto	Fusión de DataSources de subreports en el DataSource del informe padre.
>> DataSourceDemanded	Inicio de la preparación de consultas (conexión, generación SQL, inyección WHERE).
<< DataSourceDemanded	Fin de la preparación. `N subs` indica cuántos subreports se han detectado.
CreateDocument	Tiempo total de generación (ejecución SQL, llenado de datos y renderizado).
Exportar a...	Serialización del documento al formato solicitado.

Subpasos detallados (dentro de CreateDocument)

Paso	Qué mide
CreateDoc.Fill SQL principal	Tiempo de ejecución de la consulta principal en SQL Server.
CreateDoc.Subreports (total)	Tiempo acumulado de todos los subreports.
Sub: [Nombre] ×N	Tiempo de un subreport concreto. `×N` es el número de veces que se ejecutó.
CreateDoc.Render principal	Tiempo de maquetación de páginas (motor DevExpress).
PostCreate.RowCounts	Filas devueltas por consulta. Ejemplo: `subreport=53`. Útil para detectar exceso de datos.

Preparación SQL (dentro de DataSourceDemanded)

Connection.Open: Apertura de conexión (suele ser 0 ms si hay pooling).
GetSql: Tiempo de traducción de la consulta visual a texto SQL.
RecordSelectionFormula: Muestra el filtro aplicado (ej: IdDoc = 6378).
WHERE-INJECT: Filtro inyectado directamente en la tabla.
WHERE-INJECT-FK: Filtro mediante subselect de clave foránea (optimizado para servidor).
WHERE-NOINJECT: No se pudo filtrar en servidor; la consulta trae todos los datos y filtra en memoria (lento).

Cuándo pulsar el botón «Detalles» (Columna D)

En ListadoResumen: Muestra un informe completo con porcentajes de tiempo. Es la mejor forma de ver el "cuello de botella" de un vistazo.
En WHERE-INJECT / FK: Permite ver la cláusula SQL exacta inyectada para validarla.
En DataSourceDemanded.GetSql: Muestra el SQL completo (JOINs y Select). Copie este código para probarlo directamente en SSMS si la consulta es lenta.
En pasos "Sub:" elevados: Identifica exactamente qué subreport está penalizando el tiempo.

Resumen de diagnóstico rápido

Localice la línea ListadoResumen para ver el tiempo total.
Si el mayor tiempo es Fill SQL principal → Optimice la consulta principal.
Si el mayor tiempo es un Sub: específico → El problema es ese subreport o su falta de filtrado.
Si el mayor tiempo es Render principal → El diseño del informe es muy complejo (muchos elementos visuales), no es un problema de SQL.
Revise PostCreate.RowCounts → Si una consulta devuelve miles de filas innecesarias, falta un filtro WHERE.