Differences

This shows you the differences between two versions of the page.

--- abap:perf [2015/10/06 17:25] – ginko
+++ abap:perf [2016/04/28 15:30] – ginko
@@ Line 7: / Line 7: @@
 ===== itab =====
   * Le ''LOOP AT .. WHERE'' passe par un optimiseur alors que pour le read table, ça doit être fait à la main avec le ''BINARY SEARCH''.
-  * Si la table peut être immutable et posséder une clé primaire unique, la déclarer en ''HASHED'' et faire les ''READ TABLE .. WITH TABLE KEY'' et les ''LOOP AT .. WHERE'' sur la clé.
+  * Si la table peut posséder une clé primaire unique, la déclarer en ''HASHED'' et faire les ''READ TABLE .. WITH TABLE KEY'' et les ''LOOP AT .. WHERE'' sur la clé.
-  *  Si la table peut être immutable mais ne possède pas l'unicité de la clé, la déclarer en ''SORTED''.
+  *  Si la table ne possède pas l'unicité de la clé, la déclarer en ''SORTED''.
-  * Si la table est mutable, toujours la trier par la clé avant de faire un ''READ TABLE .. BINARY SEARCH'' ou un ''LOOP AT .. WHERE'' sur la clé.
+  * Si la table est ''STANDARD'', toujours la trier par la clé avant de faire un ''READ TABLE .. BINARY SEARCH'' ou un ''LOOP AT .. WHERE'' sur la clé.
+  * Si la table est ''SORTED'' ou ''HASHED'', elle ne supportera pas les ''APPEND'', il faudra utiliser des ''INSERT'' (avec le léger surcoût d'insertion du au tri ou à l'algo de hashage).
 ====== Parallel cursor ======
 Le parallel cursor est une technique pour lire efficacement 2 tables internes liées par une jointure de type "entête-poste". Elle consiste à optimiser les nested loops en passant par un read table binary search, prendre le ''sy-tabix'', faire la nested loop ''FROM'' cet index et boucler jusqu'à ce que la clé change. [[http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/e0e648f4-e001-2d10-9cbd-ec128b3812b1?overridelayout=true&46493021918586|Sauce]]