Nun ja, das ist immer so eine Sache mit der Performance.
IFS_Read ist wirklich schnell, da die Datei während des Lesens geöffnet bleibt.
Von IFS_Write empfehle ich euch, die Finger davon zu lassen, da die Performance grottenschlecht ist.
Warum?
Ganz einfach:
IFS_Write macht einen Open, schreibt die Zeile und schließt die Datei wieder. Da es sich ium das IFS handelt, erfolgt beim Schließen ebenso das Schreiben auf die Platte, da es hier keine Cachefunktion gibt.

Ich musste bei einem Kunden eine Performanceanalyse machen um zu prüfen, warum bestimmte Aktionen so lange dauern. Wenn ein User darauf warten muss, ist es immer schlecht für den Eindruck.
Der Engpass war hier tatsächlich der IFS_Write.
Hintegrund ist hier, dass Druckformulare als HTML-Templates vorliegen, durch eine RPGLE gefüllt werden, anschließend ins IFS kopiert und in PDF umgewandelt werden.
Das HTML-Template wird per IFS_Read in eine QTEMP-Tabelle geschrieben, die Formulardaten ergänzt und per IFS-Write dann ins IFS ausgegeben.
Nun, was soll ich sagen, das Einlesen und verarbeiten dauerte knapp 1-2 Sekunden, das Schreiben ins IFS 12-15 Sekunden, die PDF-Erstellung 1 Sekunde.
Also habe ich den IFS_Write mit einem CPYTOSTMF ersetzt. Dieser dauerte ca. 0,5 Sekunden.

Somit dauerte die Formularerstellung nun nur noch 2-3 Sekunden.

Fazit:
Nicht alle SQL-Anwesiungen sind sinnvoll einzusetzen.