Skip to Content

<body><p>First off, I’d like to apologize for the delay since my last ABAP trapdoor article. I’m really grateful for all of the kind responses I’m getting for these articles. However, having a 14-months-old toddler around invariably implies having all kind of germs around, and some of them apparently teamed up to knock me out for some time…</p><p>As you certainly all know, there are numerous ways to iterate through an internal table. Probably the most popular ones are <tt>LOOP AT table INTO line</tt>, <tt>LOOP AT table ASSIGNING <fs></tt> and <tt>LOOP AT table REFERENCE INTO dref</tt>. Everyone should be aware about the performance issues and side effects that can arise when using the different versions – most importantly, <tt>LOOP AT … INTO …</tt> performs a copy of every single table line while the other variants only move around pointers or addresses. On the one hand, this means that for ‘wide’ tables a lot of time is consumed to push data around, but it also implies that you have to copy the data back into the table after modifying it whereas the other variants allow in-place editing of the table contents. </p>

<p>I’m a curious person. I wanted to know how much slower it would be to copy the contents of the table around instead of editing it in-place, so I hacked together a small program that performs a number of iterations on tables of various sizes and compares the time taken for the different variants. Now I’m not an artist, but my graphical capabilities are sufficient to generate basic diagrams:</p><p>

<img  />//weblogs.sdn.sap.com/weblogs/images/252023839/LOOP-Performance-Wide.png|height=435|alt=LOOP Performance (Wide Tables)|width=700|src=https://weblogs.sdn.sap.com/weblogs/images/252023839/LOOP-Performance-Wide.png|border=0!</p>

<p>This chart shows how much time it takes to iterate over tables of varying width (10k lines each, only the size of the line changes!) up to approx 32k characters. I’ve added moving average lines to the charts because for various reasons (probably alignment, page sizes and other memory management effects) the data points bounce around  rather wildly. (Feel free to e-mail me for the full-size images, raw data or the source code of the program.) As you can see, the <tt>ASSIGNING</tt> (green) and <tt>REFERENCE INTO</tt> (blue) variant are nearly identical when it comes to time consumption, whereas the <tt>INTO</tt> (red) variant can be much more expensive. </p>

<p>Again just out of curiosity, here’s a detail shot of the table sizes between 1 and 1000 characters:</p><p>

<img  /></body>

To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

        1. Volker Wegert Post author
          Clemens,

          read my mind, did you? I was thinking about including your soulution (copying the entire table) as well, but decided against it. Of course that’s much faster if you need to copy the entire table.

          I try to avoid the LOOP-EXIT-pattern wherever possible – and that’s surprisingly often. Most of the time, it can be replaced by choosing a hashed table type and an O(1) READ TABLE access.

            Volker

          (0) 
  1. Siegfried Boes

    Hallo Volker,And please note, the scaling of the search in internal tables is the much more important topic, as it determines whether the runtime of a nested loop scales linearly (actually: lin*log) or quadratically!

    (0) 
  2. Michelle Crapo
    I’m still falling.  It’s a nice catch.  I have wondered before why it didn’t work, but never spent the effort to find out why, I just changed my code.

    I wonder… Does this have any effect on the memory / paging?

    Maybe I’ll have to try some things myself. When I get the time 🙂

    I’m busy reading great blogs like this one.

    Nicely done!

    Michelle

    (0) 

Leave a Reply