performance on Abapinho

Passar tabelas internas por valor é bom

Mon, 11 Jul 2016 09:00:21 +0000

Quando um método devolve um valor como RETURNING este é sempre passado por valor e não por referência. Muitas vezes faço métodos que devolvem tabelas internas, algumas bastante grandes. Mas sempre me preocupou a ideia de que, como está a ser devolvida por valor, o ABAP devolva uma cópia da tabela interna, algo que pode ter impacto na performance e na memória que o programa gasta.

Felizmente fiquei recentemente a saber que não é assim.

Índices secundários em tabelas internas

Mon, 25 Jan 2016 09:00:47 +0000

Durante anos as tabelas internas eram declaradas assim:

DATA: itbl TYPE TABLE OF bkpf.

DELETE vs CLEAR vs REFRESH vs FREE

Mon, 27 Jul 2015 09:00:01 +0000

DELETE CLEAR REFRESH FREE

São várias maneiras de limpar os dados de uma tabela interna. À partida parecem iguais. Mas não são.

Ensina o ABAP a fazer malabarismo

Mon, 18 May 2015 09:00:13 +0000

O que podemos fazer quando as noites não são suficientes para os processamentos diários?

Usarás TRANSPORTING NO FIELDS

Mon, 09 Mar 2015 09:00:02 +0000

Muitas vezes fazes READ TABLE itbl ou LOOP AT itbl apenas para verificar se um registo existe (CHECK SY-SUBRC = 0). Ora para isso, os dados do registo não são realmente necessários. Nestes casos usa sempre TRANSPORTING NO FIELDS. Assim evitas ter de declarar uma estrutura destino e o programa fica mais rápido porque não tem de perder tempo a copiar dados.

INNER JOIN vs FOR ALL ENTRIES vs RANGES artificiais

Tue, 25 Nov 2014 09:00:13 +0000

Uma vez que as operações de dados estão muito mais optimizadas no servidor de base de dados do que no ABAP, é sempre preferível o primeiro. FOR ALL ENTRIES só deve ser usado quando não se conseguir fazer INNER JOIN (como com a BSEG por exemplo). Quando possível, usar RANGES artificiais é preferível a usar FOR ALL ENTRIES mas é preciso cuidado para não ultrapassar o limite do parser de SQL.

Não farás SELECT *

Thu, 04 Sep 2014 11:25:03 +0000

Tenta seleccionar sempre apenas os campos que vais realmente usar. Escolher todos é um desperdício de recursos. Excepção feita ao uso das FM *_SINGLE_READ que, embora leiam os campos todos, fazem cache dos dados, sendo por isso ainda assim mais rápidos de usar quando usados múltiplas vezes com a mesma chave. Se queres apenas verificar que um registo existe, selecciona apenas um campo, e se possível aquele que estás a usar como critério, evitando assim declarares uma variável extra.

Usarás FIELD-SYMBOLs em vez de variáveis de estrutura

Thu, 24 Jul 2014 09:00:50 +0000

READ TABLE itbl ASSIGNING é sempre mais rápido que READ TABLE itbl INTO wa. Além disso, quando precisares de alterar dados em registos de uma tabela interna, assim não precisas de usar o comando MODIFY nem da variável auxiliar que às vezes usas para guardar o SY-TABIX. A única situação em que uma variável de estrutura é aconselhada é quando queres adicionar linhas novas a uma tabela interna. Algumas pessoas defendem que as variáveis de estrutura devem ser usadas sempre que não se quiser alterar os dados da tabela interna.

SELECT dentro de SELECT

Mon, 26 May 2014 09:00:03 +0000

Provavelmente por razões históricas, os programadores ABAP não exploram as possibilidades do SQL. Muitos há que em vez de usarem INNER JOINs, ainda julgam que é mais rápido fazer vários SELECTs para tabelas internas e depois trabalhar os dados em ABAP. Mas a verdade é que, mesmo que se haja excepções, a regra é: quanto menos acessos à base de dados, melhor a performance. E faz sentido porque, afinal, porque foram escritas explicitamente para isso, as bases de dados relacionais são muito mais peritas em processar dados relacionais do que um programa ABAP.

Mas claro que há coisas que, pela sua complexidade, não podem ser feitas com um simples INNER JOIN. Ainda assim, algumas dessas coisas podem ser feitas num único SELECT.

Com muitos campos evita INTO CORRESPONDING FIELDS

Mon, 10 Jun 2013 09:00:27 +0000

Já avisei aqui que, em tabelas com muitos campos, é sempre de evitar fazer SELECT *, devendo-se sempre seleccionar explicitamente apenas os campos necessários.

Mas não avisei ainda que há ainda outra optimização que merece ser feita: evitar o INTO CORRESPONDING FIELDS OF TABLE.

SORTED em vez de STANDARD nas tabelas de cache

Mon, 01 Apr 2013 16:11:22 +0000

Há bastante tempo atrás escrevi aqui um artigo demonstrando as vantagens de usar tabelas internas com índices definidos em vez de simples tabelas STANDARD. Confissão: é tal o hábito instalado que desde então, quase todas as tabelas internas que criei continuaram a ser STANDARD TABLE. É muito frequente criar tabelas internas para fazer cache de dados que sei que vou utilizar amiúde dentro de LOOPs para evitar fazer SELECT SINGLEs lá pelo meio.

Análises parciais na SE30

Mon, 28 Nov 2011 11:37:25 +0000

Claro que já conheces a transacção SE30 (Análise de tempo de execução) e claro que a usas amiúde para analisar programas standard e descobrir nele tabelas, funções, BADIs e quejandos. Ora se fores como eu, manténs uma relação de amor-ódio com esta transacção: se por um lado a amas por graças a ela consegues ver as entranhas de um programa sem ter de fazer debug, por outro lado odeia-la porque normalmente a lista de entranhas costuma ter milhares de linhas e tornar-se ingerível.

LOOP ASSIGNING em vez de LOOP INTO

Sat, 02 Jul 2011 12:25:03 +0000

No princípio era o INTO. Aliás, no princípio nem sequer era o INTO.

Soneca

Fri, 17 Jun 2011 11:43:28 +0000

Volta não volta é preciso meter um programa a dormir. E como em quase tudo, há várias formas de o fazer, e umas formas são melhores do que outras. A forma mais standard de conseguir isto em ABAP é a seguinte: WAIT UP TO 10 SECONDS. A vantagem do WAIT UP TO N SECONDS é que o processo é libertado durante estes 10 segundos, ficando assim disponível para quem o quiser apanhar.

Partida... lagarta... fugida!

Tue, 24 May 2011 09:00:41 +0000

Senhoras e senhores, meninos e meninas, a corrida está prestes a começar.

Introdução

Apresento-vos as 4 participantes. São 4 tabelas internas, de diferentes raças e credos, que se vão pelejar pelo título atlético do LOOP em velocidade. Aqui estão elas:

Concorrente 1: DATA: LT_ITEM TYPE TABLE Concorrente 2: DATA: LT_ITEM_HASHED TYPE HASHED TABLE Concorrente 3: DATA: LT_ITEM_SORTED TYPE SORTED TABLE Concorrente 4: DATA: LT_ITEM TYPE TABLE + INTO INDEX

LOOP FROM INDEX

Thu, 10 Mar 2011 12:15:12 +0000

É muito fácil meter os pés pelas mãos no que toca a performance quando se manipula tabelas internas. Principalmente quando elas são assim a tender para o grandalhonas. É até comum que estes problemas só surjam passados uns meses, quando as tabelas tendem a crescer com o tempo. Por exemplo, quando fazes loop a duas tabelas, uma de cabeçalhos e outra de itens, fazes assim? LOOP AT itab1 ASSIGNING <fs1>. LOOP AT itab2 ASSGNING <fs2> WHERE field1 = <fs1>-field1.

SAT - A nova ferramenta de análise de execução

Wed, 16 Feb 2011 14:31:40 +0000

Desde pequenino que uso a transacção SE30 para duas coisas diferentes: Analisar um programa que desconheço (normalmente standard) para saber que funções usa, que BADIs disponibiliza, etc; Analisar um programa meu em busca de problemas de performance. A verdade, nua e crua, é que a transacção SE30 é uma porcaria pegada. Extremamente limitada e inflexível, não dá jeito nenhum para qualquer análise mais complexa. Aparentemente os senhores da SAP concordam e resolveram substitui-la pela fantástica nova ferramenta SAT - ABAP Runtime Analysis , em tudo mais sofisticada.

Macros - Velocidade de ponta

Wed, 16 Sep 2009 02:37:52 +0000

Normalmente quando há um pedaço de código que pretendemos reutilizar várias vezes, transformamo-lo numa sub-rotina que pode depois ser invocada repetidamente. Embora a SAP não saiba estruturar o seu próprio código, ainda assim, o ABAP, coitadinho, permite-o. E até disponibiliza várias alternativas para modularizar o código. Eu conto quatro alternativas que listo aqui, da mais rígida para a mais flácida: METHOD, FUNCTION, FORM, DEFINE. Se os 3 primeiros são já familiar de todos, o último - DEFINE - quase ninguém usa. O DEFINE permite definir macros em ABAP. E o que são macros? São sub-rotinas aparentes.

Aparentes porquê?

READ TABLE blablabla TRANSPORTING NO FIELDS

Thu, 20 Aug 2009 04:51:19 +0000

Por vezes ao fazer READ TABLE a uma tabela interna queremos apenas verificar se um determinado registo existe, e não nos preocupamos com os dados retornados. Algo tipo: READ TABLE lt_kna1 INTO wa_kna1 WITH KEY kunnr = l_kunnr. CHECK SY-SUBRC = 0. Ora já que a estrutura WA_KNA1 não vai ser necessária de qualquer forma, mais vale não a usar, usando antes a opção TRANSPORTING NO FIELDS: READ TABLE lt_kna1 TRANSPORTING NO FIELDS WITH KEY kunnr = l_kunnr.