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: 

Which methodology should be followed to enhance performance?

0 Kudos

I have written same code in two different approach. Which is the best way to code to increase performance?

Through Class and Methods:

CLASS zcl_alv_display DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .
  PUBLIC SECTION.
    CLASS-METHODS factory
      RETURNING
        VALUE(ro_object) TYPE REF TO zcl_alv_display .
    METHODS start_of_selection .
  PROTECTED SECTION.
  PRIVATE SECTION.
    DATA gt_ekko TYPE TABLE OF ekko .
    METHODS display_alv .
    METHODS display_error_msg .
    METHODS get_data .
ENDCLASS.

CLASS ZCL_ALV_DISPLAY IMPLEMENTATION.
  METHOD display_alv.
    DATA: lo_alv TYPE REF TO cl_salv_table.
    FREE: lo_alv.
    cl_salv_table=>factory(
        IMPORTING
          r_salv_table = lo_alv
        CHANGING
          t_table      = me->gt_ekko ).
    lo_alv->display( ).
  ENDMETHOD.

  METHOD display_error_msg.
    MESSAGE 'No data found!' TYPE 'E'.
  ENDMETHOD.
  METHOD factory.
    CREATE OBJECT ro_object.
  ENDMETHOD.

 METHOD get_data.
    SELECT * FROM ekko INTO TABLE gt_ekko.
  ENDMETHOD.
  METHOD start_of_selection.
    me->get_data( ).
    IF gt_ekko IS NOT INITIAL.
      me->display_alv( ).
    ELSE.
      me->display_error_msg( ).
    ENDIF.
  ENDMETHOD.
ENDCLASS.

************** In SE38 **************

INITIALIZATION.
  FREE go_alv.
  go_alv = zcl_alv_display=>factory( ).
START-OF-SELECTION.
  go_alv->start_of_selection( ).

Through Form...Endform:

INITIALIZATION.
  DATA: gt_ekko TYPE TABLE OF ekko.

START-OF-SELECTION.
  PERFORM get_data.
  IF gt_ekko IS NOT INITIAL.
    PERFORM display_alv.
  ELSE.
    PERFORM display_error_msg.
  ENDIF.

FORM get_data.
  SELECT * FROM ekko INTO TABLE gt_ekko.
ENDFORM.

FORM display_alv.
  DATA: lo_alv TYPE REF TO cl_salv_table.
  FREE: lo_alv.
  cl_salv_table=>factory(
      IMPORTING
        r_salv_table = lo_alv
      CHANGING
        t_table      = gt_ekko ).
  lo_alv->display( ).
ENDFORM.

FORM display_error_msg.
  MESSAGE 'No data found!' TYPE 'E'.
ENDFORM.

The SE30 Analysis:

Although the time taken is almost same, but when it comes to complex logic and more records from the database tables, which methodology should be followed for better performance and maintenance of the code?

Please Help!!

1 ACCEPTED SOLUTION

matt
Active Contributor

First of all, this is just Subhajir Roy learning programming, not a real program. In the real world, you wouldn't bother with this program, you'd just use SE16. As a sample program, thoughts about maintainability are irrelevant. But let's pretend it's a real program with a real requirement.

There is no performance different. The difference lies in ease of maintenance and enhancement. "Easy" does not mean "Easy for folk who've not really learned how to program in ABAP Objects". That's Luddite thinking.

In this situation, don't use FORMs at all. It's not worth it, it adds no value. However, if it's worth using subroutines at all then it's worth using classes and methods.

1) FORMs are obsolete

2) (and I've been caught by this, hence my disagreement), a simple report often grows into something more complex. By coding it properly in an OO style, you accommodate enhancementst far more effectively.

In summary -why not do things properly in the first place? Get into good habits.(See my comment concerning the OP's variable naming).

10 REPLIES 10

Former Member
0 Kudos

Performance should be no big difference, but in terms of maintenance, il go with form..endform (Classic 😄 )

fball
Explorer
0 Kudos

I agreed with classic form..endform, in my opinion there is no advantages to use an OO approach in a simple report

Ahhh... but

Read the SAP help. Form/Endform is now obsolete.

And if you are going to use an ALV grid and use the object ALV version which has better functionality, why not continue with that and use objects throughout ?

0 Kudos

Hi Richard, i can't find nothing about form/endform is obsolete. can you send me a SAP Help links? thanks

0 Kudos

Thanks Horst, i'm reading now

pokrakam
Active Contributor
0 Kudos

Please come join us in this decade 🙂 My copy of "Official ABAP Programming Guidelines" from 2009 already threw PERFORM into the "Obsolete" bucket.

nomssi
Active Contributor

1) Write the specification first

If I ask for a list of purchasing documents...

  • created this year in US plants
  • for hazardous material in plant YXZ
  • created in month of June 2017 with value over 100.000 USD
  • or for all contracts for company 1234

then, it is obvious that your code will have to be heavily reorganized. So for better maintenance, write the specification first! The specification should allow any domain expert to test the created code tell if it is correct or not.

Then create modules (classes/function modules/forms whatever) based on an abstract domain model. Use name for your abstractions that use the language of the domain you are working in. From my requirements, who could easily find abstractions names like plant, material, period, contract, purchase orders. I would call your class VIEWER instead of ALV_DISPLAY. If you abstract processes, then a function module ALV_DISPLAY makes sense.

2) You have to measure your code to improve it

Use transaction SAT to check where you need performance improvements.

my 2 cents,

JNN

matt
Active Contributor

First of all, this is just Subhajir Roy learning programming, not a real program. In the real world, you wouldn't bother with this program, you'd just use SE16. As a sample program, thoughts about maintainability are irrelevant. But let's pretend it's a real program with a real requirement.

There is no performance different. The difference lies in ease of maintenance and enhancement. "Easy" does not mean "Easy for folk who've not really learned how to program in ABAP Objects". That's Luddite thinking.

In this situation, don't use FORMs at all. It's not worth it, it adds no value. However, if it's worth using subroutines at all then it's worth using classes and methods.

1) FORMs are obsolete

2) (and I've been caught by this, hence my disagreement), a simple report often grows into something more complex. By coding it properly in an OO style, you accommodate enhancementst far more effectively.

In summary -why not do things properly in the first place? Get into good habits.(See my comment concerning the OP's variable naming).