Medición del tiempo de ejecución

[LouieBoy]

Buenas, A ver... si ejecutais una herramienta de medicion varias veces podeis haceros una idea de lo q puede tardar el programa, me explico, si ejecutas la herramienta 20 veces, y el programa tarde de entre 10 a 15 minutos (para decir algo...) entonces es "problema" del programa si el tiempo que he mencionado antes varia de 10 a 20 luego 30, 40, otra vez 20, etc.. eso significa q la ejecución es lenta por culpa de sobrecarga del sistema, es cuestión de hacer un poco de estadistica .
Otra cosa es q quieras optimizar el codigo, mirate cuantos selects-endselect hay por ahi supongo q podras recortar bastante tiempo de ejecucion.
Respecto a lo de la query veo q utilizas muchos rangos en la seleccion, esto te puede relentizar muchisimo la consulta, utilizar mas indices puede ser una buena solucion, otra idea, es intentar delimintar los rangos, como por ejemplo declararlos como obligatorios o intentar utilizar paramentros, en lugar de tanto select option, no se si utilizaras toda la clave para acceder a la tabla pero esto tambien ayuda bastante, otro recurso es utilizar una vista donde hagas una selección previa de dicha tabla donde descartes resultados que por logica no necesitas.

En fin, espero haber sido de ayuda.

Saludos.

LouieBoy

[jsanz]

Hola foro.
No llevo mucho tiempo con SAP pero me ha tocado retocar código para optimizarlo hace poco y esto es un poco lo que pude sacar en claro:

Al principio de este hilo se plantearon unos porcentajes. Navegando un poco por documentación nos dicen que estos porcentajes no deberían de exceder del 50% en el caso de sentencias ABAP y del 30% de consultas a BD, dejando el 20% al sistema.
De todas formas estos valores dependen de qué tipo de funcionalidad tenga el programa, claro está, de hecho no suele ser fácil cumplirlos en cuanto tengas unas cuantas tablas con un gran volumen de datos.

·Es importante utilizar tablas internas con SELECT ... INTO TABLE <itab> y
después hacer LOOP en la tabla interna en vez de SELECT ... ENDSELECT.
·Siempre que se pueda utilizar SELECT SINGLE ...
·Es más rápido (según la documentación) un select largo como el que se pone
más arriba que un SELECT * (incluso aunque cojas todos los campos ).
·Utilizar INNER JOIN antes que FOR ALL ENTRIES, y utilizar vistas en lugar que
INNER JOIN.
·Realizar lo select por índices o campos claves de las tablas.

Seguro que hay gente que sabe muuucho más sobre el tema y las herramientas para solucionarlo, pero esa es mi aportación.
Espero que sea de ayuda.

[marcpelao]

Hola a todos,

este es mi primer post ... He estado leyendo lo interesante de la medición del tiempo de ejecución. He entrado en las transacciones que nombráis pero no llego a entender varios conceptos. Alguien tiene algun manual sobre el tiempo de ejecución o algo?

gracias

[BY_MY]

Otra consulta,creo que tiene relacion con esto, Cuando me pongo en modo debuging por ese codigo que tengo que optimizar, si voy linea por linea me salta un dump (yo intuyo que podria ser por los tiempos de respuesta o algo asi pero no tengo ni idea). Posteo el mensaje del dump.


¿podriais decirme algo? porque me pasa a menudo que funciona una transaccion pero en modo debuggin peta



Err.tmpo.ejec. DBIF_RSQL_INVALID_CURSOR
Excep. CX_SY_OPEN_SQL_DB
Fecha y hora 04.01.2007 11:44:03



Txt.brv.
Invalid interruption of a database selection.



¿Qué ha sucedido?
Error in ABAP application program.

The current ABAP program "ZMMPR_LISTADO_BASE_CONTRATOS" had to be terminated
because one of the
statements could not be executed.

This is probably due to an error in the ABAP program.
Unable to perform database selection fully.
record.



Anál.errores
An exception occurred. This exception is dealt with in more detail below
. The exception, which is assigned to the class 'CX_SY_OPEN_SQL_DB', was
neither
caught nor passed along using a RAISING clause, in the procedure
"SELECCIONAR_DATOS" "(FORM)"
.
Since the caller of the procedure could not have expected this exception
to occur, the running program was terminated.
The reason for the exception is:
One of the database selections included a database commit.
The selection was then supposed to continue. Before a
database commit, however, all outstanding database selections must be

[LouieBoy]

Hola, Esto es pq estas debuggeando una sentencia SELECT... ENDSELECT.
Cuando estas manejan un gran volumen de datos al hacer debuggin peta...
Es uno de los inconvenientes de usar este tipo de instruccion, por eso siempre q puedo vuelco todo el select sobre una tabla interna y luego hago un loop sobre esta y realizo las operaciones q necesite.

Saludos,

LouieBoy

[BY_MY]

ok gracias. Eso que dices es lo que estoy haciendo pero no por el debbuging sino por repartir las cargas ya que tira casi todo de BB.DD. incluso en select endselect anidados y los estoy pasando a loop at de tablas internas.

Parece ser que asi aumenta el rendimiento.



Muchas gracias y feliz año.

[javibest]

De eso no estoy totalmente seguro . Puede ser que dentro del select enselect haya introducido un commit work and wait , y puede ser debido a esto por lo que salta el dump .

[cosmica]

Gente: Algunos Tips sobre performance:

- Evitar logica negativa en los selects.
- No utilizar OR's en los SELECTS.
- Utilizar APPEND LINES OF i_tab para unidir dos tablas internas.
- Evitar el loop where, utilizar mejor loop check.
- Evitar el into corresponding fields of table, utilizar into table (poner los campos en el mismo en que fueron definidos en la tabla interna).
- Cuando accedan a tablas transparentes como las MARA, y demas que generalmente contienen muchisimos datos, eviten de ser posible los inner join, porque llevan muchisimo tiempo, traten de realizar selecciones separadas a distintas tablas internas y las unen por alguna tecnica de posicionamiento.
- No utilizar select * a menos que levanten mas del 70% de los campos que tiene la tabla.

Espero que les sirva!
Saludos,