In the previous blogs of this series (see below) the objects that were investigated with the Code Inspector were 'program-like', that is reports, function groups, or ABAP OO classes.

Code Inspector performance checks series:

1. Code Inspector's Performance Checks (I)
2. Code Inspector's Performance Checks (II)
3. Code Inspector's Performance Checks (III)
4. Table attributes check  (discussed in this blog)

But the tool can do a lot more to improve the software quality than just analyzing ABAP source code. In principle, all types of repository objects can be checked with respect to consistency of their technical properties.
 
In this blog I want to present the 'Table attributes check' of the Code Inspector, which analyzes the definition of ABAP data dictionary tables and views.

The properties of a database table or a database view are maintained within the ABAP dictionary (transaction SE11), for example on the tab strip 'Delivery and Maintenance' or in the 'Technical Settings'. Unfortunately, the ABAP dictionary does not assist you to choose table properties that are consistent and reasonable from the performance point of view.
The Code Inspector 'Table attributes check' provides messages if technical properties, buffer settings, or index settings appear to be dissonant. Please note that the Code Inspector has a simple rule set to identify such real or just would-be inconsistencies. Some of the simple rules of the 'Table attributes check' might need to be overruled by the wise developer in special cases.

Here is a short introduction into the most important technical parameters of a table or view in the data dictionary:

Delivery Class
This parameter determines, how the data in the table will behave during system installation, upgrade, client copy, and in a transport between systems. The most important delivery classes are A for application data and C for configuration data. Further delivery classes are L, G, E, S , and W. You can get more information on the delivery class within the fields' F1-help on tab strip 'Delivery and Maintenance' in transaction SE11.

Data Class
For some database platforms, this parameter determines in which physical area of the database the table will be created. The Code Inspector tool uses the data class as a categorization of the table with respect to it's data content. Since this influences some of the tools' check results, you should correctly maintain whether a table contains master data (data class APPL0), transactional data (APPL1), or configuration data (APPL2).

Size category
The size category is also maintained in the technical settings and is used to determine and reserve the initial size of a table in the database. The Code Inspector uses this parameter as an indicator for the real size of the table in production use.

Table class
This parameter determines the type of a table; the relevant ones for this check are TRANSP (transparent table), CLUSTER (cluster table), POOL (pooled table), and VIEW (general view structure).

Buffering and Buffering types
Tables that are frequently read during production use, but only rarely modified, such as those containing configuration data, should be buffered on the application server. The access to data in a buffered table is 10-50 times faster than accessing data in a non-buffered table, being read from the database cache.  In the technical settings of a table in transaction SE11, you are able to turn on the table buffering and select the buffer type (fully buffered, generically buffered, or single record buffering).

In the following diagram I depicted, how delivery class, data class, and buffering should be combined for (most of) the tables in your system. This diagram also reflects some of the rules according to which the Code Inspector 'Table attributes check' evaluates dictionary tables. As mentioned, there might be a few tables that do not fit into this scheme.  

Examples on how to read this diagram:

• delivery class C (customizing table) should not be combined with data class APPL1 (transactional data)
• a table that contains configuration data (APPL2), and which is assigned to delivery class S (system table), should be buffered
• a master data table (APPL0) with delivery class A (application table) should not be buffered, except if it has only a few entries (size category 0, or single record buffered with size category 0, 1, or 2)

Indexes

Frequently executed database statements must be supported by a database index to allow a fast search of the required entries. There are some rough rules for database indexes: for example, there should not be too many indexes defined for one table. Also, two different indexes of one table should not have too many common fields.

Messages of the check

In the following I want to present the messages of the 'Table attributes check' and give you some hints what can be done to improve.

Messages 0001, 0002: No Table Class or Delivery Class Chosen; No Data Class or Size Category Chosen
Maintain these table categorizations. They are used by the Code Inspector to evaluate database accesses.

Messages 0003, 0004: "Buffering Permitted, but switched Off" Selected
From a performance point of view, this buffer setting should be omitted. You as developer should know whether some table is suited for buffering or not. Only if a table might be small at customer A and very large at customer B, this setting makes sense and should be selected.

Message 0010: Buffering Type is Initial but Delivery Class Is "C", "G", "E" or "S"
According to it's delivery class, the reported table is a configuration table (C or G), or a system table (delivery class E or S). Such tables are normally small and get rarely changed. Therefore they should be buffered. If the reported table does not contain configuration data or system data, you may have assigned the wrong delivery class to the table.

Message 0011: Buffering is Activated but Delivery Class Is "A" or "L"
According to it's delivery class, the reported table contains application data (A), that is master or transactional data, or it is a table with temporary data (delivery class L). In both cases it is expected that the table has many entries and is changed frequently. Normally, such a table should not be buffered. Eceptions are small master data tables, which might also be buffered. If the reported table does not contain the described type of data, the delivery class might be wrongly assigned.

Message 0012: Buffering is Activated but Size Category Is > 2
Very large tables should not be buffered, even if the other preconditions for buffering are fulfilled. One effect of buffering large tables is that numerous small buffered tables might be displaced from the SAP table buffer. If only a few entries of a large table are needed during program execution, it can be reasonable to choose single record buffering or a fine granular generic buffering for this table. If the reported table has only a few entries in production use, and buffering would be appropriate, you might have assigned a wrong size category to the table.

Messages 0013, 0014: Buffering is Initial but Data Class Is "APPL2"; Buffering is Activated but Data Class Is "APPL0"/"APPL1"
Data class and buffering must be consistent. Normally, tables with data class APPL2, such as configuration tables, should be buffered. Tables of data class APPL0 or APPL1, such as master data tables or transactional data tables, should not be buffered. As an exception from this rule, small master data tables may also be buffered.

Message 0015: Buffering is Activated but No Buffering Type Is Chosen
Choose an appropriate buffering type for the reported table, based on the planned accesses. Possible buffering types are fully buffered, generically buffered, and single record buffered.

Messages 0016, 0017: Buffering is permitted but table is contained in DB view db_view; Buffering is permitted but table can be changed using database view db_view
Until NetWeaver release 6.40, it was very critical if modification of a buffered table was allowed via a database view. The reason for this was, that data changes for the view did not lead to an invalidation of the table buffer - which could lead to data inconsistencies when reading data from the buffered table. Since release 7.0 the buffer is also invalidated, if there are changes for the database view.
But what about the first message - why is it bad, if there is a database view defined for a buffered table? The rational is that if some developer decided for the additional load that is implicated by activating the buffer option, most accesses to the table really should make use of the buffering. But the existence of a database view for the table indicates that also other accesses, which are not using the buffer, are planned.
Last two comments on this check: the messages are always reported for the buffered table, not for the database view. One reason is that the 'owner' of the table should have the control on how the data is accessed. She or he should be aware of alternative access strategies that might be implemented by other developers.
If the database view is also buffered, there is no message reported. But note that any invalidation of the underlying table will also invalidate the buffered view in the table buffer.

Messages 0020, 0021: Table has more than 100 (700) fields
For technical and design reasons, a database table should not have too many fields. For Business ByDesign the more strict value of 100 fields is applied, otherwise up to 700 fields are allowed.

Messages 0022, 0023: Change Log Active Despite Data Class "APPL0" or "APPL1";
Change Log Active for Large Table
The change log for a table is activated in the technical settings by selecting the flag 'Log data changes'. If the system parameter rec/client is also set for the client, a log entry is created for every change of the table. It's clear that for master data tables and for tables with transactional data (data classes APPL0 and APPL1) no change log should be created. The same is true for large tables in general (size category > 2). Writing change logs for such tables would slow down the production system.

Message 0030: Table Has Unique Secondary Index
That's just an information message with no performance relevance.
Every developer who inserts data into such a table should be aware, that the insertion of entries which are identical with respect to the secondary index will lead to a run time error 'Insert Duplicate Keys'.

Messages 0031, 0034, 0131, 0134: Table Has More Than 4 (7) Secondary Indexes Though Data Class Is "APPL0"; Table Has More Than 2 (5) Secondary Indexes Though Data Class Is "APPL1"
A database table should no have too many secondary indexes. On the one hand, every additional index increases the cost for data insertion and modification (the latter only, if fields of the secondary index are affected). On the other hand, the cost based optimizer of the database, which calculates the data access strategies, might get puzzled by too many indexes.

Message 0032: Secondary Index sec_index: More Than 4 Fields
More than four fields can be okay for an index, for example if you are planning an index-only access. But as a rule of thumb, four or less fields should be sufficient. The client field is not counted by the check.

Message 0033: Table Has Secondary Index But Is Buffered
The existence of a secondary index for a table signals, that beside buffered accesses also secondary index accesses are planned. It must be ensured that the additional costs of both buffering and the secondary index are justified by corresponding table accesses in production use. The check only reports non-unique secondary indexes, since sometimes unique secondary indexes are defined to preclude duplicates in a table with respect to certain key combinations.

Message 0035: At Least 2 Fields ("dbfld_1" and "dbfld_2") Are Included in 2 Indexes
Indexes should not have too many fields in common with other indexes. For example, it does not make sense to have a table with a (primary or secondary) index A for the fields dbfld_1 dbfld_2 and another index B for the combination dbfld_2 dbfld_1. A different story is an index on fields dbfld_1 dbfld_2 dbfld_3 - here it could be justified to have another index on fields dbfld_3 dbfld_2. This check demands the wise developer to find out what is the appropriate solution!

Message 0036: Index idx_1 contains index idx_2 (left-aligned)
If there is an index dbfld_1 dbfld_2 dbfld_3 it does not make sense to define another index with fields dbfld_1 dbfld_2.

Messages 0037, 0137: Table dbtab: Field fld_name in primary / secondary index idx_name is of the type FLOAT
When a field of type FLOAT is read from the database, rounding differences might occur during the value assignment to an ABAP data object. If such a field is part of the table's primary key, this means that a certain table entry may not be addressed from within ABAP. If a field of type FLOAT is part of a secondary index, reasonable accesses are only possible with range conditions in the WHERE-clause of the database statement for this field.

Messages 0038, 0039: Client-specific table dbtab: Secondary index idx without client field; Client-specific table dbtab: Secondary index idx does not have client as first field
Though the client field is not very selective (and indexes should contain highly selective fields), we vote for putting it at the first position of any secondary table index, since normally the client is known for all table accesses. Secondary indexes that consist of GUIDs (Globally Unique Identifier) may get along without the client field.

Message 0041: INDX-type table dbtab is buffered
So called 'INDX-type' tables have a structure similar to that of SAP system table INDX. Such tables are normally not accessed with a SELECT statement, but with the ABAP statement IMPORT FROM DATABASE. Since this statement does not make use of any buffering, it is not reasonable to buffer an INDX-type table.

Message 0042, 0043: View dbview: First field not client, although basis table dbtab is client-specific; View dbview: Client field of basis tables dbtabs not linked using join condition
Database views based on client-dependent tables should contain the client field in the join condition. Also, the first field of the database view should be the client. Otherwise it is possible to read data cross-client with the database view, which is a security-relevant issue. The performance aspect of this issue is, that without the client field, it is possible that indexes of the tables making up the view cannot be used to optimized the data access.

Messages 0050, 0051: Language-dependent table dbtab: Language is not first field (or second after the client); Language-specific table dbtab is not buffered generically with regard to language
If a table is language-dependent, most accesses to the table will use the language field, since a user only wants to see texts in the log-on language. Therefore it is a good idea, to define the language field as the first field (or as the second field after the client), to allow for index accesses with language field plus key. Since most language-dependent tables will contain configuration data, they should be buffered. To save main memory within the buffers, such a table should not be fully buffered, but generically with respect to the language. The most important accesses, which are via the language, will then be supported by the buffer.

These are a lot of rules, but I hope they will support you to get to consistent settings for your dictionary tables and views.

In the first two articles of this series we had a look at how to best read data from database tables. The Code Inspector checks whether the database access has a WHERE clause that will be able to make use of a database index, or if an access to a buffered table will implicitly bypass the SAP table buffers.

            Articles of this series:

1. Code Inspector’s Performance Checks (I)
2. Code Inspector’s Performance Checks (II)
3. Low performance operations on internal tables (discussed in this article)
4. Code Inspector’s Performance Checks (IIII)

Now that you have read data from the database to the application server efficiently, it is essential that you streamline the way in which you deal with the data inside your program.
One big threat to the scalability of a program is large internal tables that are accessed sequentially (see Runtimes of  Reads and Loops on Internal Tables). Sequential access means, that each individual entry of the internal table is accessed by the ABAP runtime in a single step loop - either until a certain key value is found, or until the end of the internal table has been reached. This implies that a sequential access can be fast - but only if the entry searched for is at the beginning of the search area. However, on average, half of the internal table has to be stepped through to find one entry with sequential search.
In contrast, optimized accesses are non-sequential and apply indexes, binary or hashed key searches. So, while the sequential access scales linearly with the amount of processed data, optimized accesses scale logarithmic or even better (i.e. constant access time independent of amount of data).

Moreover: once you start nesting internal tables in your program, for example a statement READ TABLE itab2 inside a LOOP AT itab1 ... ENDLOOP, you can get caught out by quadratic run time behavior. This will happen if the size of the two internal tables depends linearly on the amount of data processed in your program, and if the access to the inner table is not optimized.

This article presents a Code Inspector check that detects sequential (or 'non-optimized') accesses to internal tables.

Types of internal tables and accesses

In ABAP, internal tables can be specified according to the following table categories:

• STANDARD table
• SORTED table
• HASHED table

Additionally there are the generic table categories ANY TABLE and INDEX TABLE.

SORTED and HASHED tables have a table key that speeds up the table access if the key is fully specified. In the case of the SORTED table, the access can also be optimized if just the leading part of the key is specified in the READ or LOOP statement.
Fast accesses to STANDARD and SORTED tables are possible by using the table index, that is, the position of an entry in the table.
A fast access to a STANDARD table can also be achieved by using the option BINARY SEARCH in the READ accesses. To return correct results, the table must be sorted appropriately.

Sequential, 'non-optimized' accesses

The following accesses to internal tables may result in a sequential search:

• READ TABLE itab
  • READ TABLE itab WITH KEY
    For a STANDARD table, this leads to a sequential access if the option ‘BINARY SEARCH' is missing.
    For HASHED tables you get a sequential access if the table key is not fully specified, and for SORTED tables if the leading part of the key is not specified.
  • The two variants READ TABLE itab WITH TABLE KEY and READ TABLE itab FROM wa result in sequential accesses for STANDARD tables.
  • The variant READ TABLE itab INDEX idx is always optimized (and only possible for the index table types STANDARD and SORTED).
• LOOP AT itab WHERE ...
  This always leads to a sequential access for STANDARD tables.
  For HASHED and SORTED tables to be able to make use of the table keys, the WHERE clause must only contain ‘AND' conditions, and all fields must be specified with ‘EQ' or ‘='. Again, a SORTED table can make use of the leading part of the key, while for a key access to a HASHED table all key fields must be provided.
• MODIFY and DELETE
  Both statements have three basic variants:
  • MODIFY/DELETE TABLE itab FROM wa
    This is always a sequential access for STANDARD tables.
  • MODIFY/DELETE itab ... WHERE ...
    This variant behaves like the LOOP AT itab WHERE ... (see above)
  • MODIFY/DELETE itab INDEX idx ...
    This access type is always optimized (and only possible for the index table types STANDARD and SORTED)
• INSERT
  The statement INSERT wa INTO itab INDEX idx scales linearly for STANDARD tables up to a certain size, because a linear index has to be maintained. At some threshold value a B*-tree is created which leads to logarithmic scaling behavior for larger tables.

Details of the Code Inspector check

The check ‘Low Performance Operations on Internal Tables' has four attributes corresponding to the different table types that can be checked: STANDARD, SORTED, HASHED, and GENERICALLY typed tables.
If you define an IMPORTING parameter for a method as type ‘ANY TABLE' (that is, generically typed), the check tool will not know which non-generic table type this will be at runtime. It thus assumes that it will be a STANDARD table and accesses to the table are checked accordingly.

Note that in the global check variant ‘DEFAULT' of the Code Inspector the option to check STANDARD tables is normally de-selected.

The check itself is based on the ABAP compiler (class CL_ABAP_COMPILER) and its services. The compiler provides information like the type of an internal table that cannot be extracted easily by doing a simple source code scan. Here, the information as to whether the access to an internal table can be optimized or not is provided directly to the check framework.

The check detects non-optimized accesses to internal tables with the following statements (see above):

• READ TABLE itab
• LOOP AT itab WHERE ...
  LOOP without WHERE clause does not raise a message
• MODIFY / DELETE

In the ‘Remarks' section below you will find some additional internal table statements that may be slow, but that will not give you a message with this check.

The possible Code Inspector messages for this check are:

The last message is only relevant with Release SAP NetWeaver 7.1 and higher. It comes into play when secondary table keys are defined for an internal table. Here, the deletion of entries in a STANDARD table via a SORTED or HASHED secondary key can lead to linear runtime behavior.

How to proceed with a Code Inspector message

The static check tool has no clue about how many entries an internal table will have at runtime. Therefore, not all check messages will have the same relevance for the performance of the program execution.
Now, also you as the developer are unlikely to know exactly how many entries an internal table will have in a productively used customer system. To make things easy we propose that you only distinguish between ‘small' internal tables with a maximum of 20-30 entries on the one side, and ‘large' tables on the other side. All frequently executed accesses to large internal tables should be optimized, that is, use an index, or use a table key, or do a BINARY SEARCH. In many cases, a SORTED table will do the job (* see comment at end).

This is how you should advance in detail if there is a sequential access to an internal table:

• As with all Code Inspector messages, first check if the code will be productively used at all. If it's only a test report there may be no need for optimization.
• If the internal table that is accessed sequentially will always be small (up to 20-30 entries) at runtime, it is normally not necessary to provide an optimized access - so there is no need to define such a small table as a SORTED or HASHED table. This is also why a sequential read access to a STANDARD table only raises an ‘information' message in the check tool.
• If it's an access to a STANDARD table, and the table might become large at runtime:
  • Think about converting the table type to a SORTED table. Only if your data set is very large and has the character of a mapping table (unique keys), a HASHED table can also be appropriate.
  • A READ TABLE on a STANDARD table can be made faster with the option BINARY SEARCH. Also fast nested LOOP processing is possible with sorted STANDARD tables and BINARY SEARCH (see Runtimes of  Reads and Loops on Internal Tables). But the table must be sorted and/or kept sorted in the appropriate order. Note that a SORT is an expensive operation.
  • In newer releases of SAP NetWeaver, a secondary table key can be created. Keep in mind that this additional key will contribute to resource consumption and can only be justified by a corresponding number of read accesses.
• If it's an access to a SORTED or HASHED table (that is, a table that might become large at runtime):
  • If the WHERE clause in a LOOP statement cannot make use of the table key, because it contains OR conditions (disjunctions) or comparison operators other than ‘EQ' / ‘=', think about re-defining the fields in the WHERE clause.
  • If the table key cannot be used for a HASHED table because not all fields were available, think about switching to a SORTED table. These can make use of left-justified parts of the table key to optimize the access.
  • If there are fields missing so that the full (or left-justified part of the) table key cannot be provided, think about the fields in the table key and their order. Maybe another order or other fields would better support your access. Please be aware that changing the fields in the key of a SORTED or HASHED table to improve one access can have negative impacts on many other accesses - and even lead to syntax errors. You need a ‘holistic' approach that takes all accesses to the internal table into account.
  • In newer releases of SAP NetWeaver, a secondary table key can be created. Keep in mind that this additional key will contribute to resource consumption and can only be justified by a corresponding number of read accesses.

Remarks

There are further potentially slow operations on internal tables that are not reported by the check, but that can be observed in performance measurements:

• LOOP AT ... without WHERE clause
  If you do not apply a WHERE clause, it is expected that all table entries must be read. This may be slow, of course, for large tables. And sometimes there are CHECK statements or the like inside the LOOP ... ENDLOOP which show that in fact not all entries were needed for the processing.
• LOOP AT ... with dynamic WHERE clause.
  For dynamic accesses, the check tool cannot decide whether they will be optimized at runtime or not. Therefore no message is issued.
• READ TABLE with dynamic key components
  READ TABLE itab INTO wa WITH [TABLE] KEY (comp1) = ... (comp2) = ...
  The check tool will issue a message for the WITH KEY variant of this statement, though it may be optimized at runtime.
  On the other hand, the WITH TABLE KEY variant will not lead to a message for SORTED and HASHED tables. If, at runtime, the dynamically defined key differs from the table key, you will get a short dump.
• SORT itab
  Sorting STANDARD tables (for example to provide the correct sort order for the READ TABLE ... BINARY SEARCH) scales worse than linear with the table size, so it is a rather expensive operation. To justify the cost of one SORT operation, at least 30 READ TABLE ... BINARY SEARCH have to follow.
• Table index build up
  If a STANDARD table is filled with INSERT wa INTO itab INDEX idx, internally a new type of index will be build up when the number of entries reaches a certain threshold.
  Also, the new secondary table keys are - if they are non-unique - only build up on their first use.
  This ‘lazy' or ‘on-demand' behavior can lead to unexpected runtime delays.
• Sometimes one finds the statements MODIFY/DELETE itab FROM wa inside a LOOP ... ENDLOOP over the same table. If itab is a SORTED or HASHED table, the MODIFY/DELETE gives no check message, since the access can be optimized; for a STANDARD table it's just an ‘information' message. But the MODIFY/DELETE statements start a new internal search for the entry given by the work area wa, though often it's already known - it is the current entry processed in the LOOP.
  Therefore, for index table types (STANDARD and SORTED tables), the statement MODIFY/DELETE itab INDEX idx ... should be used inside a LOOP, where idx is the current LOOP index. The addition INDEX idx can be omitted, since it is added implicitly in a LOOP.
  
  

(*) We do not discuss here cases were you need alternative access paths to large internal tables. The situation for such a scenario will improve in future with the new secondary table keys, but is rather complex for older releases.

Do you cook? A nasty saying about developers is that they live mainly on fast food like take-out pizzas, take-out chop suey, or hot-dogs. Some people may argue that this is why software applications often lack efficiency. In this weblog I want to encourage developers to apply the rules of cooking to software, because cooking can tell us a lot about efficiency. So let’s poke our noses into the cook’s pot:

Starter: the tidy kitchen
One ‘must have’ for running an efficient kitchen is order. Have you ever tried to cook in someone else's kitchen? At first, you will waste a lot of time opening the wrong drawers and searching for the things you need: the knives, the strainer, the can opener (for cheaters only), and so on. After a while, you will be better oriented and learn where to find what you need. Unconsciously you have built up a ‘kitchen search index’ that helps you to find things faster. The clever cook will also keep his spices in a well-defined order on the shelf, for example in alphabetical order or according to their taste.

This is very similar to how you should access data in a program: every frequently executed database access, for example, should be supported by an appropriate database index. Otherwise, the database has to open too many ‘drawers’ when searching for the needed data. The same holds true for accesses to internal tables in ABAP. Do not access large internal tables sequentially, for example with a READ, w/o using an index or table key. If you do so, you act like a cook who scans dozens of identical looking spice flasks until he finds the one with the nutmeg. Instead, use sorted standard tables or internal tables with sorted or hashed key that allow a fast access.

Portions, packages, and bundles
A second thing that we can learn from cooking is portioning. If you want to cook a meal for you and your best friend, would you go to the cellar and shlep a 50kg sack of potatoes up the stairs? No - the efficient cook just fetches as much food as is needed. And if a fruit salad is on the menu, don’t get the whole fruit basket from the living room or the pantry. On the other hand, neither should you go once to get an apple, then again to fetch a pear, and once again for the banana. You are the cook, you know the recipe for the fruit salad – so just go once and get all the fruits you need, no more, no less.

Again, this gives us a hint of  how to read data from the database: not more than we (that is our application) need to do the current job. But if we know for sure that several data records from the same database table will be needed, an array fetch is better than many single fetches.  Portioning or bundling is also important for the communication between remote systems or between distinct system components, for example between a service provider and the consumer. In the same way as the cook does not want to overload himself with heavy sacks, or make superfluous walks to fetch single fruits, it is reasonable to bundle the data that is exchanged between remote systems into packages of adequate size. Packages that are too small lead to many round trips, thus increasing the overall response time. And very large packages can overload the system components and result in time outs.

Store, cache, and buffer
Speaking about superfluous round trips we return to the pantry, which saves the cook from going to the grocery store every day for food that is frequently needed like rice, sugar, or noodles (which kind of food is frequently needed in a kitchen of course heavily depends on the cook’s taste buds). So the pantry works as a kind of local store or buffer that minimizes the number of very slow round trips in favor of faster ones. Some ingredients like salt or certain spices are so frequently used in cooking, that no cook could afford even to fetch them from the pantry or from a drawer – they must be right beside the kitchen stove, always within reach.

In the world of software, buffering or caching also play an important role. Data that is frequently requested but only rarely modified (for example business configuration data) should not be read over and over again from the database. Identical information should not be extracted repeatedly from service methods that need to descend numerous levels in the program's call hierarchy to retrieve it (or, even worse: to deliver nothing). Instead, such data or information must be buffered on the application server (in the case of database tables within the SAP table buffer), or locally in the program closest to the information consumer, that is, within reach. Not caching such data or bypassing the cache is like ignoring the salt shaker next to the kitchen stove and walking down to the cellar every other minute to get a pinch of salt.

Main Course: Concurrency and Scalability
Two other important aspects of efficient cooking and programming are scalability and the concurrent use of resources. Cooks are masters in doing things in parallel. While the water is heating in the pot, and the onions are sizzling in the pan, the cook can chop the carrots (and don’t forget the soufflé in the oven!). Good kitchens are designed for parallel work: the kitchen stove has 2 or more hot plates or burners, and you will find more than one pot and more than one sharp knife. If you expect several guests, you have two choices to feed them all: first, if you still work alone, you will have to invest more time, because you cannot do everything in parallel (ever tried to chop vegetables with your right and your left hand at the same time?). Or you can hire some helping hands to prepare the meal faster. If there are no bottlenecks in your kitchen like lack of knives, pots, or burners, in principle a recipe can be scaled-up from two persons to several dozens of eaters, while leaving the preparation time nearly constant (some people say that meals coming from a canteen never reach the quality of those prepared for only a few persons. But this weblog is about cooking efficiency, not about meal quality).

What can a developer learn from cooking with regard to scalability and concurrent use of resources? If your recipe – pardon, your program – scales (linearly or better) with the amount of data to be processed, it will serve hundreds of users as well as a single one just by adding burners (CPUs, memory, disk space on multiple application servers). This only holds true, as long as there are no bottlenecks like database locks or other single resources that get overloaded and lead to a serialization of users or processes. If you have only one sharp knife, you can add as many burners, pots and helpers as you want to – they will all be idle because the onions cannot be chopped fast enough. Another threat to scalability – besides locks and resource bottlenecks – is non-linear runtime behavior. In software engineering that means an algorithm efficiency with a worse than linear (or linear times logarithmic) runtime behavior as a function of the processed data volume. In business applications an algorithm with quadratic or even cubic runtime behavior is rarely requisite, but non-linear code can often be found in deficient application coding. A prominent example are internal tables that grow with the amount of the processed data and that are accessed sequentially and in a nested way (see for example in Performance Problems Caused by Nonlinear Coding).  I never came across a quadratic effect in cooking. An example would be a big vegetable that has twice the weight of a small one of the same kind, but that needs to boil four times as long (and that cannot be cut into pieces for some reason). Have you ever encountered such a non-linear vegetable effect? Maybe the vegetables I tested were just too small. This is by all means the reason why application developers often ignore non-linear effects in their code: the amount of data they use for testing is too small. Or they only perform a single measurement from which nothing can be concluded with respect to scalability. If your application scales, you can keep the response times for concurrent users acceptable just by adding resources. In the same way you will be able to process a large set of independent objects in parallel tasks, thus reducing the overall processing time tremendously. But remember: precondition for this is the absence of bottlenecks and a linear or better runtime dependence on the amount of processed data.

I hope you found this excursion into cooking and software efficiency flavorful. The next time you implement a piece of program code, try to look at it with the eyes of a cook: Will your guests like its taste? And will it also be efficient?