Zeitmessungen für Java

[flaite]

Java Agent,
- der durch eine View mit ca 100 Dokumenten iteriert
- ca. 40 Felder in 48 Dokumenten ausliest und in ein Bean schreibt
- mit diesen Daten eine 12 kb große cvs Datei erzeugt

Zeit: 0.175 Sekunden (gemessen als Differenz von System.currentTimeMillis() bei Start und beendigung des Agenten

Die Datenbank ist lokal und der Rechner hat 2 GB Arbeitsspeicher. 
Eingesetzt  wird Notes7.
Der Code ist nicht Performance-optimiert.

Ich bezweifele, dass das mit LotusScript schneller geht.

(Die hier geposteten Daten werden sich ändern, weil der Agent komplexer wird).

[jBubbleBoy]

Warum?
Java und LS gehen doch über die gleiche API, schon mal mit LS versucht?

[flaite]

So viel Zeit habe ich nicht, das extra in LotusScript umzuschreiben.
Das Erzeugen und Schreiben in die Datei geht nicht über die selbe API.
Aber du hast mich auf eine Idee gebracht. Die Messung für den Teil, in dem die 12 kb cvs Datei erzeugt wird (aus einer Collection aus 48 Beans) -> 16 Milisekunden.


Gruß Axel

[flaite]

Man könnte eine Datei mit 1000 Zeilen aus 100 'a' erzeugen lassen und die Geschwindigkeit in verschiedenen Sprachen vergleichen.
Bedingung: Jede Zeile muß einzeln in die Datei geschrieben werden.
Ich übernehme Java und C#.

[jBubbleBoy]

Ich kann das in LS und Java machen

[flaite]

ok. Muß jetzt noch arbeiten. Um ca. 21 Uhr kann ich mich damit beschäftigen.

[jBubbleBoy]

für LotusScript

Code

Sub Initialize
	
	Dim filename$, filenum%
	Dim t1, t2, a%, s$, b%
	filename = "c:\temp\ls.txt"
	
	
	For a = 0 To 99
		s = s + "a"
	Next
	
	For b = 1 To 20 
		
		killFileName filename
		t1 = Timer
		
		filenum = Freefile()
		Open filename For Output As filenum
		For a = 0 To 999
			Print #filenum, s
		Next
		Close(filenum)
		
		t2 = Timer
		Print b & " --> " & (t2 - t1) * 1000
		
	Next
	
End Sub

Sub killFileName( FileName As String)
	On Error Goto ErrorZ
	Kill FileName	
	Goto EndeZ
ErrorZ:
	Resume EndeZ
EndeZ:
End Sub

Ergebnis in Millisekunden

[koehlerbv]

Das ist schlechter Code:
Dim t1, t2, a%, s$, b%    -> t1 und t2 sind jetzt Variants. Kann in die Hose gehen
s = s + "a"   -> + ist kein String-Concatenator
Print b & " --> " & (t2 - t1) * 1000    -> Typwandlung wird LS überlassen

Das Ganze geht hier gut, kann aber in der Praxis zu Ergebnissen führen, die ganz anders aussehen, als man beim Schreiben erwartet hätte. 

Bernhard

PS: Ich würde die Zeitmessung erst nach dem Anlegen des Files starten, sonst spielt hier die API des Systems mit herein und die Organisation der HDD.

[flaite]

Hier sind die Ergebnisse für C#. Dennis will nach Hause. (Ergebnisse in Milisekunden).

1:49
2:91
3:7
4:7
5:7
6:31
7:7
8:30
9:7
10:7
11:7
12:7
13:7
14:23
15:44
16:36
17:21
18:7
19:7
20:7

Code

using System;
using System.Collections.Generic;
using System.Text;
using System.IO;
using System.Diagnostics;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            
            for (int j = 1; j <= 20; j++)
            {
                Stopwatch watch = new Stopwatch();
                watch.Start();

                StringBuilder sb = new StringBuilder(100);
                for (int i = 0; i < 100; i++)
                {
                    sb.Append("a");
                }
                StreamWriter sw = File.CreateText("C:\\temp\\myCShark.txt");
                for (int i = 0; i < 1000; i++)
                {
                    sw.WriteLine(sb.ToString());
                }

                sw.Close();
                watch.Stop();
                Console.WriteLine(j.ToString() + ":" + watch.ElapsedMilliseconds.ToString());


            }

            Console.ReadLine();

        }
    }
}

Der Code kann sicher noch bedeutend optimiert werden. Das gleiche gilt für den bald folgenden Java Code.

[jBubbleBoy]

@bernhard
Wie sieht denn ein "String-Concatenator" aus?

[koehlerbv]

&

[jBubbleBoy]

Code

s = s & "a"

So ?

[flaite]

Werte für Java:
1-->31ms
2-->31ms
3-->0ms
4-->16ms
5-->15ms
6-->16ms
7-->0ms
8-->16ms
9-->14ms
10-->15ms
11-->16ms
12-->16ms
13-->15ms
14-->16ms
15-->15ms
16-->16ms
17-->15ms
18-->16ms
19-->16ms
20-->16ms

Code

import java.io.BufferedWriter;
import java.io.File;
import java.io.FileWriter;
import java.io.IOException;


public class IOTest {
	public static void main (String args[]) {
		for (int j= 1; j< 21;j++) {
			long timeStart = System.currentTimeMillis();
			File file = new File("C:/temp/javaNoEsLento.txt");
			BufferedWriter bw = null;
			try {
				bw = new BufferedWriter(new FileWriter(file));
				StringBuilder sb = new StringBuilder(); 
				for (int i=0; i<100;i++) {
					sb.append('a');
				}
				
				for (int i= 0;i<1000;i++) {
					bw.write(sb.toString() + "\n");
				}
				
			} catch (IOException e) {
				// TODO Auto-generated catch block
				e.printStackTrace();
			} finally {
				try {
					if (bw != null) bw.close();
				} catch (IOException ioe) {
				
				}
				System.out.println(j + "-->" + (System.currentTimeMillis() - timeStart) + "ms");
				
			}
			
		}
		
		
	}

}

Zugegeben weisen die 0ms auf gewisse Messungenauigkeiten hin.

[koehlerbv]

Code

s = s & "a"

So ?

Ja.
Und hier
Print b & " --> " & (t2 - t1) * 1000
muss es heissen:
Print b & " --> " & Cstr ((t2 - t1) * 1000)

Sowie:
Dim t1 As Single

Das Thema wurde hier im Forum schon oft behandelt, auch Beispiele für die Nebeneffekte bei der "freizügigen" Typkonvertierung sind zu finden (u.a. von Axel Janssen).

Bernhard

[koehlerbv]

@Axel: Und was ergibt jBlasenJungs Code auf Deiner Kiste? Derartige Vergleiche lohnen sich ja nur identischen Umgebungen.

Bernhard

[jBubbleBoy]

Mein Java-Ergebnis, nach dem Code von Axel, musste nur StringBuilder mit StringBuffer austauschen.

[jBubbleBoy]

@bernhard
deine Anmerkungen habe ich schon verstanden, nur sehe ich keinen Unterschied zwischen + und & beim Verbinden von Stringketten.

[flaite]

Hier sind meine Daten für den LotusScript Agenten (lokal in Notes7 gestartet).

[koehlerbv]

@bernhard
deine Anmerkungen habe ich schon verstanden, nur sehe ich keinen Unterschied zwischen + und & beim Verbinden von Stringketten.

Dann lies nach oder warte einfach, bist Du das erste Mal auf die Nase fällst. Für den Anfang kannst Du ja einfach mal
Messagebox 100 + "200"
ausprobieren, dann weisst Du, auf welch dünnem Eis Du da gehst.

Bernhard

[flaite]

Mit Java1.4 wird der erste Durchlauf deutlich langsamer (0.125 Milisekunden).
Die anderen sind aber genau wie bei Java6 (Test vorher).
StringBuilder gibts erst seit Java5. Ist ein bischen schneller. Man sieht aber, dass diese Performance-Optimierung in unserem Test im Milisekunden-Bereich keine Auswirkungen zeigt.