COBOL
ID DIVISION.
PROGRAM-ID. BLOAT.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 THE-TEST-STRINGS.
05 FILLER OCCURS 11584 TIMES.
10 TEST-STRING PIC X(11584).
LOCAL-STORAGE SECTION.
01 FIRST-TIME-FLAG PIC X VALUE "Y".
01 DISP-BEFORE-STRING COMP PIC 9(8).
01 LOOP-COUNTER COMP PIC 9(8).
01 START-STRING.
05 FILLER OCCURS 0 TO 11584 TIMES
DEPENDING ON DISP-BEFORE-STRING.
10 FILLER PIC X.
05 THE-SUBSTRING PIC X(12).
01 INITIAL-STRING PIC X(12)
VALUE "HELLO WORLD!".
LINKAGE SECTION.
01 STRING-PARAMETER PIC X(11584).
01 THE-RESULT PIC X.
PROCEDURE DIVISION USING
STRING-PARAMETER
THE-RESULT
.
IF FIRST-TIME-FLAG = "Y"
PERFORM SET-UP-STRINGS
END-IF
PERFORM
VARYING LOOP-COUNTER
FROM 1
BY 1
UNTIL LOOP-COUNTER
GREATER THAN 11584
OR STRING-PARAMETER
EQUAL TO TEST-STRING
( LOOP-COUNTER )
END-PERFORM
IF STRING-PARAMETER
EQUAL TO TEST-STRING ( LOOP-COUNTER )
MOVE "Y" TO THE-RESULT
ELSE
MOVE "N" TO THE-RESULT
END-IF
GOBACK
.
SET-UP-STRINGS.
PERFORM
VARYING LOOP-COUNTER
FROM 0
BY 1
UNTIL LOOP-COUNTER
EQUAL TO 11584
MOVE 11584 TO DISP-BEFORE-STRING
MOVE SPACE TO START-STRING
MOVE LOOP-COUNTER TO DISP-BEFORE-STRING
MOVE INITIAL-STRING TO THE-SUBSTRING
MOVE START-STRING TO TEST-STRING
( LOOP-COUNTER + 1 )
END-PERFORM
MOVE "N" TO FIRST-TIME-FLAG
.
Un peu de connaissances peut être dangereux.
Il peut être plus rapide de faire une grande comparaison que de nombreuses petites comparaisons; Enterprise COBOL d'IBM (jusqu'à la version 4.2) peut avoir un STOCKAGE DE TRAVAIL maximum de 128 Mo (la version 5.0 peut avoir 2 Go); LOCAL-STORAGE offre 128 Mo supplémentaires si vous avez besoin de plus d'espace.
La tâche consiste à confirmer qu'un élément de stockage de 1 584 octets a la valeur "BONJOUR MONDE!" quelque part, et le reste est l'espace.
Le programmeur fictif décide d'écrire un sous-programme pour cela (juste au cas où cela serait nécessaire ailleurs) et d'inclure sa technique performante (bonus).
Le programmeur calcule que 11584 * 11584 est de 128 Mo. Il utilise donc WORKING-STORAGE pour une énorme table et LOCAL-STORAGE pour tout le reste.
Le programmeur le code et se sourit sciemment lorsque la compilation est propre. Ils avaient raison sur les 128 Mo.
Teste le code. Ça marche. Peut-être un peu lent, mais il y a une lourde charge sur la machine. Sourit à nouveau, pensant à quel point ce serait lent s'il était codé sans leur niveau de connaissance experte.
Le WORKING-STORAGE est de 134 189 056 octets, et il y a aussi quelques octets d'autres choses. Devrait être assez grand.
La réalité est que faire une comparaison longue au lieu d'une comparaison courte, comme mis en œuvre ici, est un moyen très lent de le faire.
Encore plus lent, le LOCAL-STORAGE, qui est initialisé par des routines d'exécution à chaque appel d'un sous-programme, entraîne la configuration de 128 Mo pour chaque CALL.
Le programmeur avait tout simplement tort sur la taille de la table, il y a assez de place sans utiliser LOCAL-STORAGE. Les comparaisons longues peuvent battre les comparaisons courtes, mais uniquement lorsque le nombre réel de comparaisons est réduit.
J'ai envisagé d'échanger LOCAL-STORAGE et WORKING-STORAGE, il est beaucoup moins probable que quelqu'un le coderait de cette façon, donc je ne l'ai pas fait. Mettre un ESPACE DE VALEUR sur la table (s'il avait été en LOCAL-STORAGE) aurait initié la table deux fois à chaque APPEL, donc encore plus lentement.
Le Bloat ne peut pas être supprimé sans réécrire le programme. La plupart du code est mauvais, bien qu'il existe une technique utile.
Ce n'est pas un exemple réel, mais je peux imaginer quelqu'un le faire, si cette personne est assez intelligente :-)
La compilation n'est pas un problème du tout. L'exécuter avec toutes les possibilités s'avère rapidement inutile.
Bien sûr, il y a aussi un vieux bug. Très courant dans les tâches de "recherche".