Wieso schneller trotz weniger?

walter_b · Beiträge: 135 Windows Vista/XP Delphi 6

Grenzgaenger hat folgendes geschrieben:

wo kommt denn hier das selbe raus?

V1: binlm := HexStrToString(DecodeText('KGS!@#$%', anf)) + HexStrToString(DecodeText('KGS!@#$%', ende));

V2: binlm := DecodeText('KGS!@#$%', anf) + DecodeText('KGS!@#$%', ende);

denke doch, dass das was anderes ist, oder? :roll:

Nein, ist das selbe, da du bei Variante 1 noch etwas vergessen hast.

markieren

V1:

1:
2:

binlm := HexStrToString(DecodeText('KGS!@#$%', anf)) + HexStrToString(DecodeText('KGS!@#$%', ende));
endhash:=StringToHexStr(binlm);

Und genau der highlightete Teil Erstellt wieder den ursprünglichen String. Schau mein Posting vorher an mit den Textausgaben.

Ehemaliges Mitglied Erhaltene Danke: 1

walter_b hat folgendes geschrieben:

Nein, ist das selbe, da du bei Variante 1 noch etwas vergessen hast.

V1:

markieren

Delphi-Quelltext

1:
2:

binlm := HexStrToString(DecodeText('KGS!@#$%', anf)) + HexStrToString(DecodeText('KGS!@#$%', ende));
endhash:=StringToHexStr(binlm);

Und genau der highlightete Teil Erstellt wieder den ursprünglichen String. Schau mein Posting vorher an mit den Textausgaben.

nein habe ich nicht. dieser teil fehlt bei deiner 2. variante.

walter_b · Beiträge: 135 Windows Vista/XP Delphi 6

Grenzgaenger hat folgendes geschrieben:

nein habe ich nicht. dieser teil fehlt bei deiner 2. variante.

markieren

Schnellere Variante (136 Sekunden bei 1 Mia Durchgängen):

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:

  bigpass:=Copy(AnsiUpperCase(Wort)+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0,0,14);
  anf:=parityshift(Copy(bigpass,0,7));
  ende:=Copy(bigpass,8,7);
  ende:=parityshift2(ende);
  alpha:=DecodeText('KGS!@#$%',anf);
  beta:=DecodeText('KGS!@#$%',ende);
  alpha:=HexStrToString(alpha);       // Umwandeln
  beta:=HexStrToString(beta);         // Umwandeln
  binlm:=alpha+beta;
  endhash:=StringToHexStr(binlm);     // Zurückwandeln

markieren

Langsamere Variante (141 Sekunden bei 1 Mia Durchgängen):

1:
2:
3:
4:
5:
6:
7:

  bigpass:=Copy(AnsiUpperCase(Wort)+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0,0,14);
  anf:=parityshift(Copy(bigpass,0,7));
  ende:=Copy(bigpass,8,7);
  ende:=parityshift2(ende);
  alpha:=DecodeText('KGS!@#$%',anf);
  beta:=DecodeText('KGS!@#$%',ende);
  binlm:=alpha+beta;     // Kein Umwandeln und kein Zurückwandeln

Ich bin nicht sicher, aber ich glaube, wir sprechen aneinander vorbei. Ich sage, dass endhash von Variante 1 das selbe ist, wie binlm von Variante 2. Bei der ersten Variante wird zuerst umgewandelt und wieder zurückgewandelt (siehe Highlight), was jedoch nichts verändert, wie die Textausgabe bewiesen hat. In der zweiten Variante wird nichts Umgewandelt und folglich auch nicht zurückgewandelt.

Oder was genau meinst du?

Ehemaliges Mitglied Erhaltene Danke: 1

und du meinst die variable: endhash ist die selbe wie die hier: binlm wenn es um die weiterverarbeitung geht?

:roll:

walter_b · Beiträge: 135 Windows Vista/XP Delphi 6

Genau. Und die Textausgabe hat das auch gezeigt!?

Zitat:

Nach dem DecodeText ist anf '695109ab020e401c' und ende 'aad3b435b51404ee'. Nach dem HexStrtoString sind beide Werte ziemlich hässlich, sehr unschöne Sonerzeichen. Nach dem alpha+beta sind die beiden "hässlichen" Strings einfach aneinander gehängt, und nach StringtoHexStr ist der Endstring '695109ab020e401caad3b435b51404ee'. Also einfach anf und ende aneinander gehängt.

Ohne das HexStrToString und StringToHexStr wird aus '695109ab020e401c' und 'aad3b435b51404ee' ebenfalls '695109ab020e401caad3b435b51404ee'.

Anderer Meinung?

delfiphan · Beiträge: 2684 Erhaltene Danke: 32

Identische Bedingung heisst auch, dass du nicht zuerst Funktion 1 und danach sofort Funktion 2 testest, weil die Reihenfolge durchaus einen Unterschied machen kann. Weiss nicht, in wiefern da der Cache und Branch Prediction eine Rolle spielen. Jedenfalls vertraue ich nur Vergleiche unter identischen Bedingungen. Kannst du mal das komplette kompilierbare Projekt posten.

Bei deinem ersten Beispiel ist bei mir der zweite Code ein bisschen schneller als der erste. Eigentlich so wie's zu erwarten wäre.

AxxiD · Hält's aus hier Beiträge: 3

ich würd ja sagen dass dein pc einfach besser mit strings arbeiten kann also mit HexaStrings!
und genau das macht dann den unterschied

aber sei doch froh dass du dein programm hast optimieren können!

MfG

alzaimar · Verfasst: So 20.07.08 16:35

AxxiD hat folgendes geschrieben:

ich würd ja sagen dass dein pc einfach besser mit strings arbeiten kann also mit HexaStrings!

Meine Vermutung ist eher, das die amerikanische CPU mit Umlauten nicht umgehen kann (Umlaute gibts im Englischen ja nicht).

Erinnert mich an einen Artikel in der Computer-Bild:
Frage: "Ich habe mir einen US-Film im AVI-Format downgeloadet, kann ihn mir aber nicht anschauen, ich höre nur den Ton. Wieso?"
Antwort Computer BILD:
"Ganz einfach, das amerikanische Video-Format NTSC ist inkompatibel zu unserem PAL-System. Besorgen Sie sich einen Software-converter, dann können Sie sich den Film anschauen"
:rofl:

_________________
Na denn, dann. Bis dann, denn.

Ehemaliges Mitglied Erhaltene Danke: 1

alzaimar hat folgendes geschrieben:

AxxiD hat folgendes geschrieben:

ich würd ja sagen dass dein pc einfach besser mit strings arbeiten kann also mit HexaStrings!

Meine Vermutung ist eher, das die amerikanische CPU mit Umlauten nicht umgehen kann (Umlaute gibts im Englischen ja nicht).

Sicher? Ich frag mich, wie er überhaupt das selbe rausbekommen kann, wenn die Variablen doch anders belegt werden. So, hier etwas zu sagen, ist nichts anderes als Kristallkugel zu lesen und walter_b hat ja nicht wirklich vor, hier erhellend beizutragen. Immer nur verstümmelte Codefragmente, ich krieg die Krise :evil:

walter_b · Beiträge: 135 Windows Vista/XP Delphi 6

Jungs, Jungs, nur keine Panik.

Ich war gerade nicht im Forum.

Zuerst einmal an alzaimar: Darüber weiss ich bescheid, deshalb habe ich Umlaute gezielt ausgegrenzt! Hier spielen definitiv keine Umlaute mit.

@delfiphan: Hm... dann habe ich wohl ein getunetes Delphi mit einem Spezialcheat.

Aber so wies aussieht, liegts dann wohl an meinem Delphi.

@Grenzgaenger: Tut mir leid, wenn ich dich nerve, aber ich dachte immer, dass man hier im Forum lieber den Code sieht, als ständig das Projekt anhängt. Und wegen dem Code: Ich muss schnell bei meinen 27 Versionen des Programmes auf dem PC suchen, welche die richtige ist. Danach werde ich zwei Projekte durch editieren diesem Posting anhängen: Dasjenige mit dem max() und die zweite mit dem umwandeln. Bis gleich

Edit: Hier hab ihr. Um zu vergleichen, müsst ihr jeweils die Auskommentierten Zeilen wieder aktivieren.

delfiphan · Beiträge: 2684 Erhaltene Danke: 32

So wie's aussieht verwendet der Compiler für die Variablen andere Register bei den Fällen mit/ohne max(). So ist die Zählvariable X der Hauptschleife beim Fall von max() eax, und beim Fall ohne max() edi. Das könnte die Geschwindigkeitsdifferenz ausmachen.

Ehemaliges Mitglied Erhaltene Danke: 1

Also, wie zu erwarten ist die erste procedure, im gegensatz zu deinen angaben, durchweg schneller.

ausserdem, es bleibt bei, dass die routinen etwas anderes machen. hier noch mal, deine beiden routinen:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:
79:
80:
81:
82:
83:
84:

procedure Gen2();
var  
  X, Y:  Integer;
  Wort:  String;     // Direkt String
  fChar: PChar;
  binlm, bigpass: string;
begin
  SetLength(Wort, 1);         // String = 1 Zeichen lang
  fChar  := @Wort[1];         // Pointer auf den 1. Char --> schneller Zugriff
  fChar^ := Chr(Ord('A') - 33);

  for X := 0 to combs do
  begin
    Y := 1;
    inc(fChar^);

    while Wort[Y] > 'z' do
    begin
      inc(Y);

      if Y > Length(Wort) then
      begin
        SetLength(Wort, Y);     // Eventuell String verlängern
        Wort[Y] := '!';
      end
      else
        inc(Wort[Y]);

      Wort[Y - 1] := '!';
    end;
  bigpass:=Copy(AnsiUpperCase(Wort)+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0,0,14);
  anf:=parityshift(Copy(bigpass,0,7));
  ende:=Copy(bigpass,8,7);
  ende:=parityshift2(ende);
  alpha:=DecodeText('KGS!@#$%',anf);
  //alpha:=HexStrToString(alpha);
  beta:=DecodeText('KGS!@#$%',ende);
  //beta:=HexStrToString(beta);
  binlm:=alpha+beta;
  //endhash:=StringToHexStr(binlm);
  end;
end;
procedure Gen3();
var  
  X, Y:  Integer;
  Wort:  String;     // Direkt String
  fChar: PChar;
  binlm, bigpass: string;
begin
  SetLength(Wort, 1);         // String = 1 Zeichen lang
  fChar  := @Wort[1];         // Pointer auf den 1. Char --> schneller Zugriff
  fChar^ := Chr(Ord('A') - 33);

  for X := 0 to combs do
  begin
    Y := 1;
    inc(fChar^);

    while Wort[Y] > 'z' do
    begin
      inc(Y);

      if Y > Length(Wort) then
      begin
        SetLength(Wort, Y);     // Eventuell String verlängern
        Wort[Y] := '!';
      end
      else
        inc(Wort[Y]);

      Wort[Y - 1] := '!';
    end;
  bigpass:=Copy(AnsiUpperCase(Wort)+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0,0,14);
  anf:=parityshift(Copy(bigpass,0,7));
  ende:=Copy(bigpass,8,7);
  ende:=parityshift2(ende);
  alpha:=DecodeText('KGS!@#$%',anf);
  alpha:=HexStrToString(alpha);
  beta:=DecodeText('KGS!@#$%',ende);
  beta:=HexStrToString(beta);
  binlm:=alpha+beta;
  endhash:=StringToHexStr(binlm);
  end;
end;

Einloggen, um Attachments anzusehen!

walter_b · Beiträge: 135 Windows Vista/XP Delphi 6

Meine Angaben stimmen, wenn ich beide Prozeduren ausführe und beide Zeiten ausgeben lasse, dann ist bei mir diejenige mit dem umwandeln schneller. Wenn es bei dir anders ist, dann freue ich mich zumindest darüber, dass es bei mir dadurch schneller wird.

Und ich weiss nicht recht, wie ich deine Performance deuten soll, bzw. was bei den beiden Varianten anders laufen soll.

Ehemaliges Mitglied Erhaltene Danke: 1

Hier hast du Recht, hier ist die Variante mit Len schneller. Weshalb? - da solltest dir den generierten Assembler Code ansehen.

---Moderiert von Narses: Beiträge zusammengefasst---

walter_b hat folgendes geschrieben:

Und ich weiss nicht recht, wie ich deine Performance deuten soll, bzw. was bei den beiden Varianten anders laufen soll.

deine GEN routine ist die erste schneller, welche weniger macht. Wo die performance haengen bleibt, ist der Aufruf deiner (Sub-) Routinen, das bekommt die zweite Funktion besser hin. Hier solltest Dir das auch am bessten in Assembler ansehen und die Aufrufe manuell optimieren.

<HTH> GG

PS: hab noch mal die Zeitaufteilung nach Routinen für deine GEN Funktionen angehängt.

PPS: wenn du wirklich etwas für deine performance machen willst, solltest mal diese routine optimieren.

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:

function DecodeText(Inputtext, Key: String): String;
begin
  with TCipher_1DES.Create do
  try
    Mode := cmECBx;
    Init(Key);
    Result := EncodeBinary(Inputtext, TFormat_HEXL);
  finally
    Free;
  end;
end;

die frisst dir fast die ganze zeit auf

Einloggen, um Attachments anzusehen!

walter_b · Beiträge: 135 Windows Vista/XP Delphi 6

Vielen Dank. Ich weiss, dass diese Funktion ein Problemfall ist, bin auch schon dabei, sie zu optimieren, auch wenn sie in der DEC steckt

Aber das Problem ist, dass ich gerne 4 Mio in einer Sekunde erreichen würde. Was meinst du? Ist wohl bei weitem nicht erreichtbar, oder?

---Moderiert von Narses: Beiträge zusammengefasst---

Wie hast du diese Performances erstellt? Habe jetzt mal ein bisschen rumoptimiert, würde das gerne selbst erstellen können.

Lossy eX · Beiträge: 1048 Erhaltene Danke: 4

walter_b: Auch wenn das keine direkte Antwort auf deine Frage ist. Aber du solltest dich nicht zu sehr auf irgendwelche Messergebnisse hängen. Als kleines Beispiel. Ich hatte vor ein paar Tagen einen Code geschrieben der 6 MB Speicher X mal kopiert hat. Ich hatte die Anwendung 10 mal ausführ und hatte 10 unterschiedliche Messergebnisse bekommen. Die Zeiten lagen alle im Bereich zwischen 18 und 24 Sekunden. Was eine erhebliche Schwankung ist. Obwohl ich sonst nichts am Rechner gemacht hatte. Je nachdem ob Windows oder einer der anderen Prozesse gerade etwas machen wollte oder nicht. Deswegen bitte die Messergebniss nicht überbewerten. Und mindestens 5-10 mal testen und selbst dann kann man nur über den Daumen schätzen.

Was ich zum Beispiel lassen würde wären solche Konstelationen.

markieren

Delphi-Quelltext

1:	Copy(AnsiUpperCase(Wort)+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0+#0, 0, 14);

Um das mal zu verdeutlichen WAS ich damit meine habe ich einen Teil der CPU Ansicht als Anhang an das Post angefügt. Diese kleine Zeile Code ist ein regelrechter Brocken und es mal deutlich zu sagen. Denn du hast eine Umwandlung eines Textes (Wort) in Großbuchstaben, 15 Strings die aneinander kopiert werden sollen und dann ein Abschneiden der überflüssigen Zeichen. Alles gepaart mit mehreren temporären Strings, die alloziiert und wieder freigegeben werden müssen.

Das ist jetzt nicht böse gemeint. Aber du solltest nicht den einfachsten Weg gehen sondern versuchen zu verstehen was genau da passiert. Um solche Stellen auf Anhieb zu sehen muss man so etwas aber schon häufiger mal gemacht haben. Das CPU Fenster ist genial für solche Fälle. Denn dieses Fenster zeigt den maschinen Code einzelner Anweisungen an. Ein bisschen wissen über Assambler ist dann leider von nöten. Aber nicht viel. Nur so sieht man relativ schnell was da eigentlich passiert.

Aber folgende Verbesserungen würde ich vorschlagen.
- Schau dir mal die Methoden an. Copy, AnsiUpperCase. Alle haben einen String als Paramater und einen als Rückgabewert. Rückgabewert bedeutet, dass ein neuer String erzeugt werden muss. Wenn du den String aber nicht mehr brauchst, dann kannst du für AnsiUpperCase zum Beispiel selber etwas schreiben mit einem Var Parameter. Dann änderst du die Zeichen innerhalb des einen Textes. Deine eigene AnsiUpperCase Methode sollte mit einem Mapping array arbeiten und einfach nur die Zeichen des Textes durch die innerhalb des Array ersetzen. Das Array enthält alle Zeichencodes unverändert aber die von Kleinbuchstaben wurden zu großbuchstaben.
- Dann würde ich Stringadditionen vermeiden wo es geht. Genau so auch Copy Aufrufe. Du könntest ParityShift doch so erweitern, dass du den originalen Text und die Positionsangaben übergibst. Parityshift würde sich dann nur noch auf diese Zeichen beziehen.
- Das Beschränken des Textes auf 14 Buchstaben kannst du auch über SetLength lösen. Dann muss der Text nur ein einziges mal angepasst werden. Und wenn du dir vorher merkst wie lang es war kannst du den Rest auch mit #0 auffüllen. Das Sinnvollste wäre aber vermutlich sogar noch, wenn der Text von Hause aus gleich 14 Zeichen lang wäre und du die Zeichen nicht zu Wort addieren würdest sondern nur an die Stelle 1, 2 oder 3 schreibst. Das fällt diese ganze Arbeit von Hause aus weg.

Die beste Optimierung ist, Arbeit die nicht gebraucht wird auch gar nicht erst zu machen. Denn das spart in jedem Fall die meiste Zeit.

Wenn du es wirklich wirklich schnell hinbekommen willst, dann solltest du evtl auch mit dem Gedanken spielen die Delphi Strings sein zu lassen. Durch die automatische Referenzzählung von Delphi holst du dir jede Menge versteckten Aufwand mit in dein Programm. Und es kann schnell mal passieren, dass dort Dinge gemacht werden die man nicht erahnt. Wärend, wenn du selber alles handhaben musst, dann bleibt dir nichts anderes übrig als genau zu wissen was passiert. Wird dadurch aber auch umständlicher und schwerer. Und ist natürlich kein Garant dafür, dass es schneller werden muss. Wenn man dabei unglückliche Sachen macht, dann kann es auch langsamer werden.

PS: Du solltest evtl. deine Methode HexStrToString überdenken! Denn diese kann über ihren Speicherbereich hinwegschreiben. Du nimmst für die Länge des Rückgabewertes die Länge des Parameters DIV 2. Beispiel. Du übergibst einen Hexwert mit einer Ungeraden länge. Zu Beispiel $FF FF FF. Dann ist die Länge 3. 3 DIV 2 ist 1. Eigentlich 1,5 aber das Komma 5 fällt weg. $FF FF FF ist aber Binär folgendes 1111 1111 1111. Entsprechend werden 4 Bits des 2ten Wertes mit gesetzt. Das liegt also außerhalb deines eigentlichen Strings.

Einloggen, um Attachments anzusehen!

_________________
Nur die Menschheit ist arrogant genug, um zu glauben sie sei die einzige intelligente Lebensform im All. Wo nicht mal das nachhaltig bewiesen wurde.

walter_b · Beiträge: 135 Windows Vista/XP Delphi 6

Vielen Dank für deine Ausführlichen Erklärungen. Dass diese Textstelle nicht optimal ist, war mir von Anfang an klar. Ich hatte 6 verschiedene Versionen, wie diese Aufgabe angegangen wird und dies ist eine davon (und auch nicht die beste

). Da bei diesem Falle das Mysterium mit dem HexToString aufgetaucht ist, habe ich den Code einfach mal so gepostet. Aber den habe ich mittlerweile auch schon optimiert. Im Moment sieht die Stelle wie folgt aus:

markieren

Delphi-Quelltext

1:
2:

  for I:=Length(Wort) to 14 do
    Wort:=Wort+#0;

Und bis und mit dieser Funktion erreicht der Programmteil 4 Millionen Durchgänge in 16 Millisekunden. Da wären wir gleich beim nächsten Punkt, nähmlich den Zeitangaben. Ich mache immer mindestens 3 mal den gleichen Durchgang, und bei mir waren bisher noch nie grössere Abweichungen als 50ms festzustellen. Aus diesem Grund schaue ich die Messwerte, welche ich erhalte, doch als einigermassen repräsentativ an. Mit Dem Bild, wie du es angefügt hast, kann ich irgendwie nicht besonders viel anfangen. Ich sehe zwar, dass er den einen Schritt 14 mal macht, jedoch wäre für mich noch interessant zu sehen, wie lange er auch dafür benötigt. Aus diesem Grund interessiert es mich, wie Grenzgaenger seine Performance erstellen konnte. Bin wohl zu noobig für deine Version.

Und keine Angst, das mit dem HexToString war nicht wirklich meine Absicht, dies so im Code zu lassen. ^^

Lossy eX · Beiträge: 1048 Erhaltene Danke: 4

CPU-Ansicht: Na ja. Man muss dafür ein bisschen Assembler können. Das braucht man zu Zeiten der Hochsprachen normal aber nur für wirklich spezielle Sachen. Aber nur eines dazu. Jedes mal wenn dort steht "CALL Blahhh", dann wird eine Methode aufgerufen. Das ist beim Verändern von Strings eigentlich jedes mal der Fall. Diese LStr* Methoden sind zwar schnell aber wenn man die einige Mio mal aufruft, dann kostet das Aufrufen der Methoden alleine auch schon seine Zeit.

Das zweite Dokument sieht so aus als ob das aus aqTime stammt. Das ist ein Profiler. Der misst wie lange einzelne Methoden aufgerufen wurden. Auf der Seite gibt es auch eine 30 Tage Testversion. Für Privat aber kaum vernünftig erschwinglich. Aber für Firmen sicher jeden Euro Wert.

_________________
Nur die Menschheit ist arrogant genug, um zu glauben sie sei die einzige intelligente Lebensform im All. Wo nicht mal das nachhaltig bewiesen wurde.

Ehemaliges Mitglied Erhaltene Danke: 1

yep, Lossy hat recht, es ist AQTime. Ein normaler profiler. Denke aber, dass es der falsche ansatz ist, welchen du verfolgst. bevor man sich mit der performance befasst, sollte man mal sehen, dass das programm überhaupt läuft... anschliessend, dass es vernünftig strukturiert und fehlerfrei ist... erst dann, schaut man, wie man es etwas schneller machen könnt... das heisst, man schaut sich einfach mal an, was man gemacht hat und wie man es eleganter machen könnte... in einem zweiten schritt schaut man, dass man dass man groebere schnitzer ausbügelt.. z.b. man überlegt sich, ob die datenstrukturen die man verwendet auch optimal zum algo passen und optimiert dann in diese richtung... sollte das noch nicht reichen, schaut man sich an, ob nicht irgendwo zu viel gemacht wird, falls doch, wird das aufgelöst und nur noch das gemacht was nötig ist (z.b. rufst du ständig die initialisierung vom DEC auf, was sehr viel kostet). im anschluss versucht man dann noch weitere optimierungen, z.b. sprünge (z. b. calls) zu optimieren, indem man die parameter und rückgabeparameter optimiert.

für das ganze braucht man noch keinen profiler, es reicht i.d.r. der gesunde menschenverstand... denn es lohnt sich was zu machen, bei funktionen/procedureen welche häufig durchlaufen werden, die einmaligen sachen, braucht man noch nicht mal anzufassen.

PS: wenn du wirklich so viel wert auf performance legst, solltest dir eine implementation in assembler überlegen

PPS: ausserdem solltest du vermeiden, ständig etwas zu machen, was du nur einmal machen brauchst (z. B. Stringupcase). dies ist auch ein nettes beispiel, was man sich schnell inline z.b. in assembler codieren kann

Ehemaliges Mitglied Erhaltene Danke: 1

walter_b hat folgendes geschrieben:

Vielen Dank. Ich weiss, dass diese Funktion ein Problemfall ist, bin auch schon dabei, sie zu optimieren, auch wenn sie in der DEC steckt

Aber das Problem ist, dass ich gerne 4 Mio in einer Sekunde erreichen würde. Was meinst du? Ist wohl bei weitem nicht erreichtbar, oder?

tja, das denk ich nicht, dass DEC hier das problem ist, sondern eher dein umgang mit dieser routine..

es reicht doch vollkommen, sie einmal zu instanzieren und nur dann zu initialisieren wenn sich das Pwd geändert hast... in deinen code machst du das aber ständig... und auch immer mit den gleichen parametern... dass sich das auf die performance niederschlägt, ist mehr als logisch...

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme