Mas Pruebas con Xailer 3.0.1

[vgest]

Estimado Jose
Una vez realizadas mas pruebas sobre nuestras aplicaciones compiladas con xailer 3.0.1, vemos que existe un problema de rendimiento respecto a la version 2.7.1, que afecta tambien al al uso de DataSets con dbf.
Hemos realizado unas pruebas de rendimiento, comparando bucles simples de operaciones con dbf (Seek, RecLock, Goto, etc) entre xailer 3 y xailer 2.7.1, siempre compilador con harbour.
Como podrás observar el rendimiento empeora bastante al usar la ultima version. El proyecto, tablas y condiciones de uso son siempre las mismas, y el resultado varia muy poco (décimas de segundo) si se ejecuta con o sin el IDE.
Quedamos a tu disposición si necesitas mas información o quieres que hagamos alguna comprobación adicional
Un saludo
RESULTADOS DE LAS PRUEBAS
-----------------------------------------
Xailer 3.0.1
----------------
Pruebas: 10000
Relativo Tiempo(ms) Descripcion
---------------------------------------------------------
1.00: 1 Asignar variable
1080.67: 1621 RecLock
165.33: 248 Seek
300.00: 450 Skip
104.67: 157 Goto
Xailer 2.7.1
----------------
Pruebas: 10000
Relativo Tiempo(ms) Descripcion
---------------------------------------------------------
1.00: 2 Asignar variable
256.67: 462 RecLock
91.67: 165 Seek
94.44: 170 Skip
38.33: 69 Goto
NOTAS:
Las pruebas realizadas simplemente miden el tiempo (Con seconds()) de un bucle de 10.000 iteraciones, en el cual se realiza cada operación.
Por ejemplo, para la prueba de seek:
for ind := 1 to nRep
Resul := oBas:Seek( time() )
next
Para la prueba de RecLock:
for ind := 1 to nRep
oBas:Skip()
if oBas:eof()
oBas:Gotop()
endif
oBas:RecLock()
next

[jfgimenez]

Victor,
> Una vez realizadas mas pruebas sobre nuestras aplicaciones
> compiladas con xailer 3.0.1, vemos que existe un problema de
> rendimiento respecto a la version 2.7.1, que afecta tambien
> al al uso de DataSets con dbf.
>
> Hemos realizado unas pruebas de rendimiento, comparando
> bucles simples de operaciones con dbf (Seek, RecLock, Goto,
> etc) entre xailer 3 y xailer 2.7.1, siempre compilador con
> harbour.
>
> Como podrás observar el rendimiento empeora bastante al
> usar la ultima version. El proyecto, tablas y condiciones de
> uso son siempre las mismas, y el resultado varia muy poco
> (décimas de segundo) si se ejecuta con o sin el IDE.
>
> Quedamos a tu disposición si necesitas mas información o
> quieres que hagamos alguna comprobación adicional
Si las pruebas anteriores de FastReports estaban hechas con DBFs, y el
rendimiento de los DBFs ha bajado tanto, entonces es de esperar que FR
no tenga nada que ver con el problema de rendimiento de la vez anterior,
sino que se trata en realidad de los DBFs. Por lo tanto, vamos a
enfocarnos en esto.
Me gustarí­a, si es posible, que me enviaras un ejemplo autocontenido,
incluidas las DBFs, para poder hacer pruebas y estudiar qué ha podido
cambiar entre las dos versiones de Harbour (la de Xailer 2.7 y la
última). Porque el problema tiene que estar en Harbour, ya que en Xailer
no hemos cambiado nada que pudiera afectar a las DBFs. Por cierto, ¿qué
RDD estáis usando?
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

[jfgimenez]

Victor,
acabo de hacer una prueba rápida con una aplicación que tengo todaví­a
con DBFs (el resto lo tengo con SQL), y no he notado ninguna diferencia
apreciable.
He utilizado un ejecutable de julio de 2012, que está compilado con
Xailer 2.6 y xHarbour, frente a otro ejecutable que he compilado ahora
mismo con Xailer 3.0 y Harbour+MinGW. Las pruebas las he hecho en el
disco duro local, y la aplicación utiliza el RDD CDX.
En ambos casos, he lanzado un listado de 184 páginas (muy simple, sin
casi ningún cálculo o proceso para que no afecte a la medida de
rendimiento de los DBFs), y los tiempos han sido pácticamente idénticos:
7.2 +- 0.2 segundos (el margen de error viene determinado por mis
reflejos al pulsar el botón del cronómetro ).
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

[vgest]

Efectivamente, los dataset de Xailer van igual de rapidos en la version 2.7 que en la 3.0.1.
Segun tus indicaciones hemos hecho un proyecto para probarlo y da resultados similares. Estamos usando CDX.
El problema es que no usamos los DataSet de Xailer, sino otros nuestros de hace mucho tiempo, y con estos si va 3 veces mas lento. Hemos revisado el codigo y es muy similar.
Incluso hemos substituido completo el codigo fuente del metodo RecLock por el del DbfDataSet, y se ejecuta 3 veces mas lento sobre nuestro DataSet que sobre el de Xailer. Este "fenomeno" solo ocurre en xailer 3.0, en xailer 2.7 va bien.
Se os ocurre a que puede deberse? No encontramos ninguna explicacion ni solucion para esto.
Un saludo

[ignacio]

Hola,
Es realmente extraño lo que comentas. Yo te recomendarí­a que intentarás hacer pruebas con apertura en exclusivo para descartar que la tabla no esté abierta dos veces: una por la aplicación y otra por el IDE. En dicho caso es muy normal que los tiempos aumenten incluso aunque sólo hagas lecturas ya que el fichero í­ndice requiere ser bloqueado constantemente.
Un saludo

[vgest]

Pero el IDE no se usa para nada en esto, no deberia influir.
En esencia lo que estamos haciendo es:
- Abrir de la forma clasica y añadir indices si no hay error:
DbUseArea( .F., Db_Driver, oBas:cFile, oBas:cAlias, .F., .F.)
- Probar con un bucle del tipo:
for ind:=1 to nRep
oBas:RecLock()
next
- El codigo del metodo RecLock lo hemos copiado y pegado del DbfDataSet de xailer.
- Esto funciona rapido en xailer 2.7.1 pero va tres veces mas lento al compilar con xailer 3
Como es posible que un mismo codigo (RecLock) vaya mas lento por pertenecer a una clase o a otra?
Un saludo

[ignacio]

vgest escribió el jue, 04 abril 2013 11:30
Pero el IDE no se usa para nada en esto, no deberia influir.
En esencia lo que estamos haciendo es:
- Abrir de la forma clasica y añadir indices si no hay error:
DbUseArea( .F., Db_Driver, oBas:cFile, oBas:cAlias, .F., .F.)
- Probar con un bucle del tipo:
for ind:=1 to nRep
oBas:RecLock()
next
- El codigo del metodo RecLock lo hemos copiado y pegado del DbfDataSet de xailer.
- Esto funciona rapido en xailer 2.7.1 pero va tres veces mas lento al compilar con xailer 3
Como es posible que un mismo codigo (RecLock) vaya mas lento por pertenecer a una clase o a otra?
Un saludo

Seguramente que su clase hago algo más que se le escapa.
Un saludo

[jfgimenez]

Victor,
>
> Pero el IDE no se usa para nada en esto, no deberia
> influir.
> En esencia lo que estamos haciendo es:
>
> - Abrir de la forma clasica y añadir indices si no hay
> error:
> DbUseArea( .F., Db_Driver, oBas:cFile, oBas:cAlias, .F.,
> .F.)
>
> - Probar con un bucle del tipo:
> for ind:=1 to nRep
> oBas:RecLock()
> next
>
> - El codigo del metodo RecLock lo hemos copiado y pegado del
> DbfDataSet de xailer.
>
> - Esto funciona rapido en xailer 2.7.1 pero va tres veces
> mas lento al compilar con xailer 3
>
> Como es posible que un mismo codigo (RecLock) vaya mas lento
> por pertenecer a una clase o a otra?
Pero, ¿estás seguro que el problema es el método RecLock()? Seguramente
es alguna otra cosa.
Ayer, Ignacio te comentó que probaras a usar las tablas en exclusivo, y
así­ descartas tanto que pudieran estar en uso por otro programa
(incluido el IDE), como que el problema sea el bloqueo. En cualquier
caso, estamos hablando por hablar. Lo ideal serí­a que nos mostraras el
código real de las pruebas, porque seguramente hay algo que se te está
escapando, y siempre siempre, 4 ojos ven más que 2
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

[vgest]

Hemos probado con shared := .f. y mejora la velocidad en un 40%, pero aun asi, va el doble de lento que el dataset de xailer en el reclock(), por ejemplo.
Hemos hecho un pequeño proyecto de pruebas con los datset de xailer, pero es muy dificil hacer lo mismo con el dataset nuestro porque es un codigo con referencias a toda la aplicacion.
Os lo podriamos mostrar, pero son tres clases hededando una de otra y es muy dificil ver a simple vista lo que hacen.
De todas formas, por muchas cosas que haga la clase, en el metodo reclock() hemos pegado literalmente el codigo del DbfDataset de Xailer. Si hacemos un bucle de 10000 llamadas a este metodo, deberí­a ejecurase a la misma velocidad, no?
Ademas, esto mismo funciona bien en xailer 2.7.
La unica explicacion racional que vemos es que las librerias de esta nueva version utilicen un nombre de funcion publica que entre en conflicto con una nuestra, posiblemente una funcion C. Pero esto es extremadamente dificil de detectar.. ¿O existe alguna forma de hacerlo?
Un saludo

[jfgimenez]

Victor,
>
> Hemos probado con shared := .f. y mejora la velocidad en un
> 40%, pero aun asi, va el doble de lento que el dataset de
> xailer en el reclock(), por ejemplo.
>
> Hemos hecho un pequeño proyecto de pruebas con los datset
> de xailer, pero es muy dificil hacer lo mismo con el dataset
> nuestro porque es un codigo con referencias a toda la
> aplicacion. Os lo podriamos mostrar, pero son tres clases hededando una
> de otra y es muy dificil ver a simple vista lo que hacen.
>
> De todas formas, por muchas cosas que haga la clase, en el
> metodo reclock() hemos pegado literalmente el codigo del
> DbfDataset de Xailer. Si hacemos un bucle de 10000 llamadas
> a este metodo, deberí­a ejecurase a la misma velocidad, no?
¿Y si lo abres en exlusivo y no llamas a RecLock()?
Y por cierto, ¿qué RDD estáis usando?
Por otro lado, cuando lo compilas con debugger, ¿muestra algo en el área
de mensajes del IDE al salir del programa? Algo como bloques de memoria
sin liberar y cosas así­.
> Ademas, esto mismo funciona bien en xailer 2.7.
> La unica explicacion racional que vemos es que las librerias
> de esta nueva version utilicen un nombre de funcion publica
> que entre en conflicto con una nuestra, posiblemente una
> funcion C. Pero esto es extremadamente dificil de detectar..
> ¿O existe alguna forma de hacerlo?
La forma más sencilla de ver si hay alguna colisión entre nombres de
función es poner trazas (logdebug()) en las funciones sospechosas, y ver
si pasa por ahí­.
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info