Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

what is the role of extended syntax check in performance tuning

Former Member
0 Kudos

hi

what is the role of extended syntax check in performance tuning

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hi,

Extended sytnax check -


check different aspects of abap programs

few are listed below those have a major contribution in performance realated issue.

<u><b>SLIN Checkbox: Dangerous Statements</b></u>

Switches on problematic statement test

This checks for the following:

1. Identical WHEN statements appear twice in a CASE statement

2. In a SELECT loop, a statement is called that results in the cursor being lost

3. Whether the programs addressed using the INCLUDE statement exist and are of type I

4. The FREE MEMORY statement is called

5. An EXPORTING parameter was mistakenly incorporated as an assignment: CALL FUNCTION .. EXPORTING arg = val. argNeu = argNeu.

6. System fields that are only to be set internally are overwritten

7. The print parameter for the line width LINE-SIZE is longer than 255 characters for the REPORT, Program, or NEW-PAGE statement.

8. Names that begin with '%_' are reserved for internal use. IDs of this type will be reported

9. The RAISE statement outside function groups

10. A numeric literal at a calculation position (ADD '1' TO ..)

11. Table commands with implicit index use outside LOOPs

12. MODULE statement in a form pool

13. ASSIGN statement that exceeds the field limit (ASSIGN field+i TO )

14. WRITE TO statement replacable with MOVE TO statement

15. Structure definitions (DATA BEGIN OF .. DATA END OF) do not just contain further DATA statements

16. STOP statement in a module or function module

17. Declaration in modules

<i><b>reward point if find helpful

Debjani lahiri</b></i>

6 REPLIES 6

Former Member
0 Kudos

Hi

Extended syntax check or SLIN is used to check the program in all aspects for the different syntaxes like

When you use select single whether you have passed all the key fields or not>

whether you have maintained the text elements texts or not,

Have you used UNIT...CURRENCY along with the QTY and AMOUNT fields when displayed using the WRITE statement

and check for all the varities of statements used in the code, and if there is some problem with that statement/command, it will display as error or warning.

Check following links -

<b>Reward points for useful Answers</b>

Regards

Anji

Former Member
0 Kudos

Hi,

<b>Extended Program Check</b>

Many checks are excluded from the standard syntax check for performance reasons. The extended program check performs a complete check that includes the interfaces of external procedures called from your program.

Errors in the extended program check cause exceptions, which in turn cause runtime errors when you run the program. You must correct them. The exception to this is coding that cannot be reached. However, you should delete this to minimize the size of your program and make the source code easier to understand.

Warnings in the extended program check should also be corrected. If your program contains statements that are definitely correct but still produce warnings in the extended program check, you can exclude them from the check using pseudocomments ( "#EC… ).

You should always run the extended program check on a new program. You have not finished developing a new program until you can run the extended program check on it without any errors or warnings. Messages are permissible, since they are generally not critical.

The extended program check is also only a static check. It cannot eliminate all of the circumstances that could lead to exception situations or runtime errors. For example, any statements in which you specify arguments dynamically as the contents of fields, or in which you call procedures dynamically, cannot be checked statically.

Regards

Sudheer

Former Member
0 Kudos

Hi,

Extended sytnax check -


check different aspects of abap programs

few are listed below those have a major contribution in performance realated issue.

<u><b>SLIN Checkbox: Dangerous Statements</b></u>

Switches on problematic statement test

This checks for the following:

1. Identical WHEN statements appear twice in a CASE statement

2. In a SELECT loop, a statement is called that results in the cursor being lost

3. Whether the programs addressed using the INCLUDE statement exist and are of type I

4. The FREE MEMORY statement is called

5. An EXPORTING parameter was mistakenly incorporated as an assignment: CALL FUNCTION .. EXPORTING arg = val. argNeu = argNeu.

6. System fields that are only to be set internally are overwritten

7. The print parameter for the line width LINE-SIZE is longer than 255 characters for the REPORT, Program, or NEW-PAGE statement.

8. Names that begin with '%_' are reserved for internal use. IDs of this type will be reported

9. The RAISE statement outside function groups

10. A numeric literal at a calculation position (ADD '1' TO ..)

11. Table commands with implicit index use outside LOOPs

12. MODULE statement in a form pool

13. ASSIGN statement that exceeds the field limit (ASSIGN field+i TO )

14. WRITE TO statement replacable with MOVE TO statement

15. Structure definitions (DATA BEGIN OF .. DATA END OF) do not just contain further DATA statements

16. STOP statement in a module or function module

17. Declaration in modules

<i><b>reward point if find helpful

Debjani lahiri</b></i>

Former Member
0 Kudos

apart from finding errors and warnings, SLIN (extended program check ) basically helps you clean up your program code. You can find out the lines in your code which are never executed or are superfluos, plus you can determine some language dependent elements which might affect the program if the logon language changes.

apart from this, you can find which variables are declared but never used in the program......and in case you are referencing some database tables with incomplete key access....

just some points.....you will see a whole lot of options when you execute SLIN

Former Member
0 Kudos

Hi,

The extended syntx check will return you details about the errors in the program, unused variables, hard coded text-elements if used, warnings etc. It returns a large amount of performance related errors too.

Regards,

Shruthi R

Former Member
0 Kudos

If you are interested in performance tuning, the Code Inspector is even better that the Extended Syntax check.

The Code Inspector incorporates the full Extended Sytax check and does even more.

For example, the Code Inspector will report detailed performance issues related to WHERE clause on SQL statements such as SELECT that might resulted in non-optimal performance, such as full table scans.

With regard to performance, the following checks are performed by Code Inspector (SCID):

<b>Analysis of WHERE Condition for SELECT</b>

<i>This check examines the WHERE condition of the SELECT statement for accesses to non-buffered tables according to the criteria below.JOINs are not processed; accesses that bypass the table buffer are not taken into consideration either.

SELECT statement does not contain any WHERE condition.

WHERE condition does not contain any field of a table index.

WHERE condition does not contain any first field of a table index.

Despite the addition ' 'CLIENT SPECIFIED', no client field in the WHERE condition.

Table does not exist or has no nametab entry.

The priority of a message depends on the size category of the table that is accessed.</i>

<b>Analysis of WHERE Condition in UPDATE and DELETE</b>

<i>The WHERE condition in the UPDATE and DELETE statements is examined.

UPDATE dbtab SET ... WHERE

DELETE FROM dbtab WHERE ...

according to the following criteria:

UPDATE/DELETE statement without WHERE condition

WHERE statement does not contain any field of a table index

WHERE condition does not contain the first fields of a table index

Despite the addition ' 'CLIENTSPECIFIED', no client field in the WHERE condition

The priority of a message depends on the size category of the table that is accessed.</i>

<b>SELECT Statements That Bypass the Table Buffer</b>

<i>With read accesses, SAP table buffering - that is, buffering of database tables on the application server - has a major performance advantage over database accesses. Therefore suitable tables should be buffered, and with buffered tables you should avoid bypassing the buffer. The following cause a bypass:

Intended bypassing: SELECT ... FOR UPDATE and SELECT ... BYPASSING BUFFER

Use in JOINs

Use in subqueries

Aggregate functions COUNT, MAX, MIN, SUM, AVG

SELECT DISTINCT ...

... GROUP BY ...

... ORDER BY ... with different sort sequence than in primary key

... IS [NOT] NULL in the WHERE condition

No explicit SELECT SINGLE with single record buffering

(Generic) key not fully specified with generic or single record buffering

Key not fully specified by CLIENT SPECIFIED on client-specific table without client field in the WHERE condition

What should be done if a SELECT statement bypasses the SAP table buffer? This check does not report the bypassing of the table buffer through the use of native SQL ans well as constructs such as SELECT * FROM dbtab AS db WHERE dbfield1 > dbfield2 .</i>

<b>Low Performance Operations on Internal Tables</b>

<i>Sequential Search with Internal Tables

This check finds out whether, in the case of internally executed search operations on internal tables, a sequential search needs to be executed. This takes place if internal tables with (incomplete) keys need to be accessed and therefore no (explicit or implicit) index can be used.

With the following statements, a sequential search can happen:

READ ...

LOOP ... WHERE ...

INSERT ...

MODIFY ...

DELETE ...

Depending on the table type, there is a difference between the various situations in which a sequential search is executed:

Standard tables

Sorted tables

Hash tables

Generic tables</i>

<b>Low-Performing Parameter Transfers</b>

<i>This check examines whether a (potentially) low-performing mode is used during the parameter transfer of a method, form, or function module. One pre-condition for such a mode is the use of value transfer instead of reference transfer (marking the parameter through VALUE(par)). If one of the following additional conditions exists, you potentially have a case for low-performing parameter transfer:

The value transfer is apparently not necessary after (*) since the parameter is not changed.

Length of the parameter type > 100 Bytes

Parameter type is an internal table

A particularly critical situation is the case where the row type of a table is itself a table since, in this case, the table sharing that normally takes place (delaying the copying of an internal table until a write access is executed) cannot be executed.

In the first case, the problem can usually be removed simply by using reference transfer. However:

(*) CAREFUL: If programming is not perfect, you can get functional errors during conversion to reference transfer !

The following cases are critical :

Double transfer of a variable to a routine although for reading (IMPORTING) as well as writing (EXPORTING, CHANGING)

Calling a form routine with USING parameter, which is changed in the corresponding form routine, however.

Read access in a routine to an EXPORTING parameter before this was written for the first time in the corresponding routine.

Also note that, when a route is terminated by a message of type E or W, VALUE-EXPORTING/CHANGING parameters are not written back to the database.

. The changes to the reference parameters, however, remain.

Code Inspector Tip: Compare between value transfer (call-by-value) and reference transfer (call-by-reference)

The test messages can be suppressed using the pseudo comment "#EC CI_VALPAR.</i>

<b>Instance Creation of a BAdI: Missing Import Parameter</b>

<i>Creating a BAdI instance uses old interface

As of SP7 of the SAP Web AS Release 6.20, two optional IMPORTING parameters can be entered for a call for instance generation of BAdIs (method GET_INSTANCE of class CL_EXITHANDLER). These parameters improve the performance of this method.

EXIT_NAME is supplied with the name of the BAdI definition as a current parameter. This can always happen and has a positive affect on performance.

NULL_INSTANCE_ACCEPTED If an X is contained here, an instance is created only when there is an active implementation for this BAdI definition. If there is no active implementation, the parameter INSTANCE stays at ZERO. This means that before a method of this BAdi is called you need to have checked whether an instance exists.

As of SP9 des Web AS Release 6.20, and there is no active, but an existing DEFAULT implementation, an instance is passed back to the BAdI definition, even if NULL_INSTANCE_ACCEPTED = X.

Prior to SP9, no instance was returned in this case.

See also SAP note number 537844 'Performance Improvements in BAdI Management'

This message can be suppressed with a pseudo comment "#EC CI_BADI_GETINST</i>

<b>Table Attributes Check</b>

<i>Checks the technical settings (transport attributes, buffering) and the secondary indices of database tables.

Standard Tests

Technical Settings, Buffering

No table class or delivery class selected

No data class or size category selected

"Buffering allowed, but switched off" selected

Buffering type is initial but delivery class is "&1"

&1 = 'C', 'G', 'E', 'S'

Buffering is activated but delivery class is "&1"

&1 = 'A', 'L'

Buffering is activated but size category is "&1"

&1 > 2

Buffering type is initial but data class is "APPL2"

Buffering is activated but data class is "&1"

&1 = 'APPL0', 'APPL1'

Buffering is aktiviert but no buffering type selected

Buffering is permitted but table is contained in view

Table has more than 700 fields

Change log active despite data class "APPL1"

Table Indexes

Table has a unique secondary index

Table has more than 4 secondary indices, although the data class is "APPL0"

Secondary index "&1" has more than 4 fields

Table has secondary index but is buffered

Table has more than 2 secondary indices, although the data class is "APPL1"

At least 2 fields ("&1" and "&2") are contained in two indices

Index "&1" is contained left-aligned in index "&2"

Table contains a field of the type FLOAT in one index

Other Table Tests

Buffering of INDX-type zables

View ignores client-dependency of basis tables</i>

-


In addition to performance checks, it will also perform security checks.

Security checks:

<b>Critical Statements</b>

<i>The test checks whether certain statements that are critical to security or endanger program stabiltiy are used. These are:

System Function Call: CALL 'cfunc' ...

Transaction Call: CALL TRANSACTION ...

Use of a 'SYSTEM-CALL': SYSTEM-CALL ...

Use of an 'EDITOR-CALL': EDITOR-CALL ...

Call of an Executable Program: SUBMIT REPORT ...

Use of Native SQL: EXEC ... ENDEXEC.

Use of ROLLBACK WORK: ROLLBACK WORK.

Use of a Database Hint: %_HINTS ...

Use of GENERATE REPORT / SUBROUTINE POOL / DYNPRO : GENERATE REPORT prog

Reading a Program/Text Pool READ REPORT / READ TEXTPOOL

Writing/Deleting a Program/Text Pool : INSERT/DELETE REPORT / INSERT/DELETE TEXTPOOL

Reading a Screen: IMPORT DYNPRO

Writing/Deleting a Screen: EXPORT/DELETE DYNPRO

Reading a NAMETAB Entry :IMPORT NAMETAB

Writing a NAMETAB Entry: EXPORT NAMETAB</i>

-


Code inspector can be accessed from within the ABAP editor using Program/Check/Code Inspector. It is transactoin code SCID, but it is best to access it through the editor.

This is all in addition to what the Extended Syntax check does.

Hope this helps.

Brian