Information in the Tables, Classes, Programs, and Expert Views in the Memory Inspector

Information in the Tables View

In the Tables view, you will find allocated and used bound memory and the allocated and used object size for each internal table, which you can also see in other views. (The Object Size and Bound Storage Size are identical for internal tables.)

You will also find these details on internal tables in the Tables view:

• Lines (Allocated) : So that rows (lines) can be added to a table without relocating the table in memory, ABAP allocates more space to each internal table than it needs . Here, you can see how many rows of each table the allocated space can hold.

• Lines (Used) : This column shows you how many table rows (lines) are currently present in the main memory allocated to each internal table.

• Usage - Lines (%) : Here, conveniently calculated for you, you can see the percentage of allocated storage in lines that is in use in each table. Tables calculates similar percentages-used for other measures of internal table memory.

• Column Width : This column shows the length of a table line in bytes. This information is also presented in other views, but is more easily extracted here.

• RefCount : Here you see the number of references ( reference counter ) to each internal table.

  More than one reference indicates that a single copy of a table body in memory is shared between multiple reference variables. (See Value Semantics in the Concepts section for more information on the ABAP copy-on-write strategy for managing internal table contents in memory.)

• tabhld : The ABAP runtime identifies internal tables by an ordinal number, which is shown in this table.

  The ordinal can help you cross-reference a table in a memory snapshot with its appearance in an ABAP Short Dump and in some other traces that use the internal table handle. For example, an ABAP Short Dump may identify a table with the internal name 'IT_<ordinal number> in addition to or instead of the table name.

Information in the Classes View

The Classes view aggregates class objects by class and includes the bound memory and object size statistics available in other views. But Classes also offers these extra class-specific details:

• Number of Instances : This column shows you the number of instances (class objects) that have been created of a particular class definition.

• Instance Size : This is an internal metric which has little significance for the analysis of memory use.

• Class Attributes : Here you see the number of attributes defined in a class. This gives you a rough indication of the size and complexity of the class.

• cladId/objhld : The ABAP runtime identifies class objects by an ordinal number, which is shown in this column. You can also see the number in the class name notation familiar from the ABAP Debugger and this transaction: {O:<ordinal number>... But the ordinal is more easily extracted here.

Information in the Programs View

The Programs view shows you all of the programs that have been loaded into the internal session that is shown in a memory snapshot or comparison of memory snapshots. The term 'programs' is used in its broadest sense to mean ABAP executables, so the Programs display includes not only ABAP reports but also function groups and class pools.

You can filter these programs by type:

• System programs that belong to the ABAP runtime and ABAP infrastructure. These include function groups and classes that provide the interface between ABAP and the ABAP kernel or that implement other fundamental services and interfaces.

  The programs are ranked by size. However, you as an application programmer have little influence over these programs. These statistics are therefore useful mostly for checking that the ABAP infrastructure is not contributing significantly to a memory problem.

• Application programs , those programs loaded explicitly by the application program that was running in the internal session.

  Here, you will see not only the ABAP application program that was running in the internal session, but also internal programs that the ABAP runtime loaded to support the program, such as programs for table management, for ALV UI elements, and so on.

  Again, you have little influence over necessary infrastructure programs. But you can verify in this view that the ABAP infrastructure that supports an ABAP application is not contributing significantly to a memory problem.

The Programs display offers an overview of the types of memory objects that each program contains. For purposes of memory analysis, these statistics are relevant only with respect to application programs, since an application developer can influence only these.

• Global Data : This figure is the initial static memory request of a program or class. This consists of the memory area for the global data of a program, including static attributes of a class (but not including class constants). In the case of deep data types, only the references for the individual data objects are stored in this area, not the objects themselves.

• Number of Instances : This column shows the number of class objects that have been instantiated in the context of the program, including instances of local classes in class pools, reports, and function groups. An ABAP report may show a Number of Instances greater than 0 if at the time of the memory snapshot the program contained non-initial references to objects of local class definitions or to objects of global class definitions.

  The Number of Instances gives an idea of the relative size of the memory referenced by the program. A program with 10 or 20 references to objects is probably not very significant in terms of memory use. A program that holds references to thousands of class objects probably should be analyzed.

• Number of Tables : This column shows the number of internal tables in the context of the program. As value-semantic memory objects , the bodies of tables (their contents) count sooner or later toward the bound memory of a program.

  In the analysis of memory use, the number of internal tables is usually interesting only if it is very high or if just a few (large) tables account for a large amount of bound storage. In the first case, you might want to understand why the program needs to work with so many tables, and whether these tables have the potential to become very large. In the case of few large tables, you might want to understand whether the tables need to be so large.

• Number of Strings : The figures in this column show the number of strings declared in the context of a program. As value-semantic memory objects , the contents of strings count sooner or later toward the bound memory of a program.

  Again, this statistic is generally interesting in the analysis of memory use only if a program uses a very large number of strings. The question then becomes whether the strings have the potential use a lot of memory and whether the program really needs to work with so many strings.

• Number of Data Objects : This column reports on the number of anonymous data objects declared in a program. As reference semantic memory objects , anonymous data objects do not count toward the bound memory of a program. They become interesting in a memory analysis if they account for a large amount of memory and/or are used in large numbers.

• progId : This column reports the ordinal number assigned by the ABAP runtime to each ABAP program. The ordinal 0 identifies the application program that initially was started.