Laufzeitoptimierung: Tuning-Challenge - Part I

[Ilja583]

Hier mal ein etwas anderes Posting, um die Kreativität der LeserInnen hier herauszufordern und gleichzeitig praktische Beispiele für Laufzeitoptimierungen zu geben.

Hierfür habe ich ein Rahmenprogramm geschrieben, was die äußeren Gegebenheiten simuliert und eine Laufzeitmessung durchführt. Als Referenz habe ich eine (schlechte) Beispiellösung eingebaut, die dafür sorgt, dass a) nur gültige Ergebnisse akzeptiert werden und b) ein Vergleich der Laufzeitverbesserung auch auf verschiedenen Systemen möglich ist, indem einfach ein Optimierungsfaktor bestimmt wird, um wieviel besser die optimierte Routine gegenüber der Referenzroutine ist.


Situation
Es ist eine Tabelle gegeben mit n Einträgen. Die Tabelle besteht aus 2 Feldern - einer (Material)nummer ( von 1 bis m ) und ein Buchungsdatum im laufenden Jahr (1.1.2004 - 31.12.2004).
An eine Unterroutine wird die gesamte Tabelle und "m" übergeben. In der Routine sollen nun folgende 3 Zahlen ermittelt werden.
1.) "Dauerbrenner" - alle Materialien, die in jedem Monat eine Buchung haben
2.) "Saisonartikel" - alle Materialien, die in 10-11 Monaten eine Buchung haben.
3.) "Ladenhüter" - alle Materialien, die in weniger als 10 Monaten eine Buchung haben.

Die genauen bezeichnungen der Variablen bzw. Strukturen ist dem Programm zu entnehmen.

Eine Referenzlösung ist mit dem Unterprogramm "REFERENZ" angegeben - die Laufzeit, die diese Routine benötigt dient als Vergleich zu der optimierten Routine.

Aufgabe
Es existiert eine Formroutine "VERGLEICH", die genauso angesprochen werden kann wie die Routine "REFERENZ". In diese "VERGLEICH"-Routine soll eigenes oder überarbeitetes Coding gestellt werden, das das Problem ebenfalls korrekt löst - aber möglichst schneller.

Regeln
- Es dürfen keine globalen Variablen definiert oder gelesen werden (insbes. nicht die Referenzlösung ).
- Globale Typen dürfen definiert werden (falls das wirklich jemand für nötig hält), damit man saubere Übergaben an weitere Unterprogramme durchführen kann.
- Weitere Forms, Makros etc. dürfen definiert werden (falls benötigt).
- Schon gepostete Routinen dürfen weiteroptimiert werden - von Jedermann.

Coding - Rahmenprogramm
wenn das hier klappt ist irgendwo ein Attachment zu sehen - in dem ist der "gezippte" Quältext

Aufruf
Ans Werk - wer holt den Hi-Score ?
VIEEEEL SPASS

[Ilja583]

Hi-Scores werden in diesem Posting gelistet. Dann muss man nicht suchen wo grad die schellste Version ist.

Ich poste aber nur Highscores, die ich auf meinem System nachgestellt habe und die hier veröffentlicht wurden. Franks Lösung z.B. kommt in die Liste (falls es dann noch die schnellste ist) sobald er es hier reinschreibt oder wenn ich nächste Woche eine Bilanz ziehe

Damit auch ein Anreiz da ist habe ich in dem Attachment oben gleich eine bessere Lösung mitgeliefert, die auf meinem System im besten Fall einen Faktor 35-40 rausholt

Tabellengröße: 10
Faktor: 4,0 Autor: Olaf P.
Quelle: siehe unten - Posting vom 27.5, 3:35am


Tabellengröße: 100
Faktor: 5,0
Autor: Olaf P.
Quelle: siehe unten - Posting vom 27.5, 3:35am


Tabellengröße: 1000
Faktor: 10,5
Autor: Olaf P.
Quelle: siehe unten - Posting vom 27.5, 3:35am


Tabellengröße: 10000
Faktor: 50,5
Autor: Olaf P.
Quelle: siehe unten - Posting vom 27.5, 3:35am


Tabellengröße: 100000
Faktor: 279
Autor: Olaf P.
Quelle: siehe unten - Posting vom 27.5, 3:35am

[Willy1492]

Ich geb's ja zu, ich habe geschummelt.
(Aber da es auch um praktische Beispiele gehen soll:
Eine generell für alle Lösungsversuche zu dieser Aufgabe geeignete Optimierung ist darin auch noch enthalten - allerdings je nach Lösung mit einem Nebeneffekt, der aber laut den genannten Bedingungen nicht verboten ist.)

Du solltest Deine Spezifikation der Randbedingungen noch mal überarbeiten.

Ich habe folgende Ergebnisse erzielt:
10
Vergleichsroutine ist um Faktor 53,11 schneller
100
Vergleichsroutine ist um Faktor 2491,70 schneller
1000
Vergleichsroutine ist um Faktor 2929,07 schneller
10000
Vergleichsroutine ist um Faktor 82752,71 schneller
100000
Vergleichsroutine ist um Faktor 6429939,43 schneller
















Spoiler-Space, falls andere selbst herausbekommen wollen, wie ich geschummelt habe





.




.




.




.




.




.




.




.




.




.




.
Hier mein Beispiel-Code:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. FORM vergleich USING    t_input     TYPE tyt_input
2.                         p_max_matnr TYPE i
3.                CHANGING p_ergebnis         TYPE ty_ergebnis.
4.   CASE p_max_matnr.
5.     WHEN 3.
6.       p_ergebnis-ladenhueter = 3.
7.     WHEN 7.
8.       p_ergebnis-saison = 2.
9.       p_ergebnis-ladenhueter = 5.
10.     WHEN 35.
11.       p_ergebnis-dauerbrenner = 10.
12.       p_ergebnis-saison = 22.
13.       p_ergebnis-ladenhueter = 3.
14.     WHEN 252.
15.       p_ergebnis-dauerbrenner = 161.
16.       p_ergebnis-saison = 90.
17.       p_ergebnis-ladenhueter = 1.
18.     WHEN 2002.
19.       p_ergebnis-dauerbrenner = 1646.
20.       p_ergebnis-saison = 355.
21.       p_ergebnis-ladenhueter = 1.
22.     WHEN OTHERS.
23.       PERFORM vergleich2 USING t_input p_max_matnr CHANGING p_ergebnis.
24.   ENDCASE.
25. ENDFORM.                    "vergleich
26.  

GeSHi ©

vergleich2 ist Deine FORM vergleich (umbenannt).

Das ist eben das Schöne an Pseudo-Zufallszahlengeneratoren mit definiertem Seed.
Die Ergebnisse sind wiederholbar.
Für Vergleichbarkeit der Ergebnisse zwar nett (sonst hat man noch mehr Streuung in der Laufzeit), für hart kodierte Ergebnislisten aber auch.

(Ich habe tatsächlich mal in einem Projekt erlebt, dass jemand die Spezifikation einer zu entwickelnden Funktion nicht verstanden hat und hart kodiert die richtigen Ergebnisse für die Testfälle zurücklieferte. Für alle anderen Fälle versagte die Funktion jedoch kläglich.)

Als weitere Variante zum Schummeln fiele mir noch ein, bereits einmal berechnete Ergebnisse in STATICS-Variablen zu speichern, so dass bei 5 Wiederholungen der Durchschnitt gedrückt wird.

[Grace3566]

Moin zusammen,
ich probiere es mal mit dieser Routine:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. FORM vergleich USING    value(t_input)     TYPE tyt_input
2.                         value(p_max_matnr) TYPE i
3.                CHANGING p_ergebnis         TYPE ty_ergebnis.
4.  
5.   DATA: buchungen_monate TYPE i.
6.  
7.   FIELD-SYMBOLS: <l_input> LIKE LINE OF t_input.
8.  
9.   SORT t_input BY material budat.
10.  
11.   CLEAR p_ergebnis.
12.  
13.   LOOP AT t_input ASSIGNING <l_input>.
14.     AT NEW budat&#40;6&#41;.
15.       ADD 1 TO buchungen_monate.
16.     ENDAT.
17.  
18.     AT END OF material.
19.       IF buchungen_monate = 12.
20.         ADD 1 TO p_ergebnis-dauerbrenner.
21.       ELSEIF buchungen_monate >= 10.
22.         ADD 1 TO p_ergebnis-saison.
23.       ELSE.
24.         ADD 1 TO p_ergebnis-ladenhueter.
25.       ENDIF.
26.       CLEAR buchungen_monate.
27. *     Ende?
28.       IF <l_input>-material >= p_max_matnr.
29.         EXIT.
30.       ENDIF.
31.     ENDAT.
32.   ENDLOOP.
33. ENDFORM.                    " vergleich

GeSHi ©

Ergebnis:
Einträge->Faktor schneller
10->1,95
100->2,29
1.000->3,49
10.000->13,79
100.000->87,25

In der Praxis sollte man auch den Jahreswechsel berücksichtigen.

VG und viel Spaß
Olaf

[Willy1492]

Zwei verschiedene Lösungen von mir, die je nach Datenmenge effizienter sind (und sich nicht auf hart kodierte Sonderfälle beschränken) , hab ich per private mail an Stefan geschickt, damit andere noch etwas zu knobeln haben.

Variante 1:
10
Vergleichsroutine ist um Faktor 3,37 schneller
100
Vergleichsroutine ist um Faktor 6,36 schneller
1000
Vergleichsroutine ist um Faktor 10,68 schneller
10000
Vergleichsroutine ist um Faktor 40,36 schneller
100000
Vergleichsroutine ist um Faktor 159,28 schneller


Variante 2:
10
Vergleichsroutine ist um Faktor 2,57 schneller
100
Vergleichsroutine ist um Faktor 3,86 schneller
1000
Vergleichsroutine ist um Faktor 7,45 schneller
10000
Vergleichsroutine ist um Faktor 34,27 schneller
100000
Vergleichsroutine ist um Faktor 257,19 schneller

Wenn genügend Zeit zum Experimentieren war, kann Stefan sie von mir aus posten.
(Ich wollte andere Leute erst mal nicht beim Ausprobieren eigener Ideen in die Quere kommen.)

Frank

[Alva1590]

Auch Beispiele, die nicht an die bisherigen "Bestwerte" herankommen, dürften interessant sein.
Eventuell ergeben sich ja mit einem anderem Betriebssystem oder SAP-Release Abweichungen in der Laufzeit der einzelnen Versionen.

[Ilja583]

Obigem Posting möchte ich mich ganz stark anschließen. Die gemessenen Faktoren variieren durchaus von System zu System - und ich würde mich freuen möglichst viele Lösungen zu sehen.

Die Lösung die mir Frank zugesandt hat ,hat auf meinem System z.B. die folgenden Faktoren.

10 1,6
100 2,1
1000 4,3
10000 19,3
100000 150,5

- die von Olaf P. geposteten Werte entsprechen grob denen auf dem System hier.
( und ich tippe, dass wenn ich die beiden kombiniere wird da noch ein klein wenig mehr rausgekitzelt )

Ach ja - ein kleiner Anreiz: Wenn man in Olafs Posting EIN weiteres Statement einfügt verbessern sich die Faktoren ab 1000 um ca. 25%.

Ich selber werde mich ab morgen mal ein paar Tage in Urlaub verabschieden, aber nächste Woche werde ich alle Lösungen die mir zugeschickt wurden sowie die hier geposteten vergleichen und eine (kommentierte) Demoroutine hinstellen, die die beste Laufzeit in etwa erreicht aber trotzdem übersichtlich genug bleibt.

[Grace3566]

Hallo zusammen,
einen habe ich noch. Diesmal geht das Coding auch via PM an Stefan.

Das Ergebnis sieht folgendermaßen aus:

10 3,02
100 3,36
1.000 6,34
10.000 29,63
100.000 238,51

VG Olaf
PS: Stefan, ich wünsche Dir einen schönen Urlaub.

[Fabian1957]

Muss noch'n bisschen drehen. Bis jetzt mal soweit:

10 -> 1,21 langsamer
100 -> 1,62 schneller
1000 -> 3,64 schneller
10000 -> 16,75 schneller
100000 -> 119,29 schneller

Hermann

[Grace3566]

Hallo zusammen,
Stefan hatte ja bereits angedeutet, dass man meine erste Variante noch ein bisschen steigern kann. Die Steigerung beträgt ca. 50%

10 2,37
100 3,14
1.000 5,32
10.000 20,69
100.000 127,28

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. FORM vergleich USING    value&#40;t_input&#41;     TYPE tyt_input
2.                         value&#40;p_max_matnr&#41; TYPE i
3.                CHANGING p_ergebnis         TYPE ty_ergebnis.
4.  
5.   DATA: buchungen_monate TYPE i.
6.  
7.   FIELD-SYMBOLS: <l_input> LIKE LINE OF t_input.
8.  
9.   SORT t_input BY material budat.
10.   DELETE ADJACENT DUPLICATES FROM t_input COMPARING material budat&#40;6&#41;.
11.  
12.   CLEAR p_ergebnis.
13.  
14.   LOOP AT t_input ASSIGNING <l_input>.
15.     ADD 1 TO buchungen_monate.
16.  
17.     AT END OF material.
18.       IF buchungen_monate = 12.
19.         ADD 1 TO p_ergebnis-dauerbrenner.
20.       ELSEIF buchungen_monate >= 10.
21.         ADD 1 TO p_ergebnis-saison.
22.       ELSE.
23.         ADD 1 TO p_ergebnis-ladenhueter.
24.       ENDIF.
25.       CLEAR buchungen_monate.
26.     ENDAT.
27.   ENDLOOP.
28. ENDFORM.                    " vergleich

GeSHi ©

Viel Spaß beim Tüfteln.
VG Olaf
PS: Ist mal eine nette Abwechslung.