Random() zu langsam?

[Kuonrat]

Hallo, ich möchte eine möglichst große Anzahl an Zufallszahlen generieren, mein Problem ist jedoch die Dauer die das Programm dafür benötigt. Das Auslesen des Arrays in eine TListBox geht mittlerweile sehr schnell dank .BeginUpdate.
Das reine füllen des Arrays dauert aber viel zu lange. Schon für 100.000 Zahlen brauch er 1min 30sek. Und ich kann mir nicht helfen warum.

Delphi-Quellcode:

procedure TFach.generate;
var i : Integer;
begin

SetLength(Items, Number+1);

for i := 0 to Number do
  begin
  Items[i] := Random(Number)+1;
  end;

end;

Man sagte mir ich soll .NET deaktivieren, ich hab leider keine Idee wie ich das machen soll, noch ob es überhaupt etwas bringt. Ich benutze Delphi 2005 Prof.

[DP-Maintenance]

Dieses Thema wurde von "Matze" von "Programmieren allgemein" nach "Object-Pascal / Delphi-Language" verschoben.
Delphi-Frage

[Khabarakh]

lol? Folgender Code benötigt nicht einmal eine Millisekunde:

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

uses
  SysUtils, Windows, DateUtils;

const
  n = 100000;
var
  i: Integer;
  Start: Cardinal;
  Data: array of Integer;
begin
  Start := GetTickCount;
  Randomize;
  SetLength(Data, n);
  for i := 0 to n - 1 do
    Data[i] := Random(n);
  Writeln(GetTickCount - Start);
  Readln;
end.

Zitat:

Zitat von Kuonrat

Man sagte mir ich soll .NET deaktivieren, ich hab leider keine Idee wie ich das machen soll, noch ob es überhaupt etwas bringt. Ich benutze Delphi 2005 Prof.

Das Projekt ist aber schon Delphi.Win32 und nicht Delphi.Net, oder?

[Sharky]

Zitat:

Zitat von Khabarakh

lol?

Hai Kraberakh,

dein "Lachen" mag ja lustig sein.... aber sage dem Fragesteller doch bitte auch warum Du das machst!
Alles andere ist nämlich unnötig.

Danke :stupid:

[3_of_8]

Es ist *nicht* ratsam, ständig neuen Speicher zu reservieren. (mit SetLength)

Besser einmal reservieren und dann so lassen.

[DeddyH]

Zitat:

Zitat von 3_of_8

Es ist *nicht* ratsam, ständig neuen Speicher zu reservieren. (mit SetLength)

Besser einmal reservieren und dann so lassen.

Hast Du mehr gesehen als ich? Wo wird denn ständig neuer Speicher reserviert?

[Matze]

Zitat:

Zitat von Sharky

aber sage dem Fragesteller doch bitte auch warum Du das machst!

Sebastians Code unterscheidet sich eigentlich nicht vom Code des Fragestellers bis auf die winzige Addition, die jedoch nicht so ins Gewicht fallen kann. Ich denke, daher lacht er.

Vermutlich benötigen andere Code-Teile so lange.

[Kuonrat]

Ich hab es jetzt mal seperat direkt auf einem Button ausprobiert. Da waren es 6 Sekunden für 1.000.000 Zahlen. Ich hab es wohl irgendwo mit meiner schlechten OOP vergeigt. Trotzdem hab ich das gefühl 6 Sekunden sei zu langsam. Im IRC hat man mir 16-17ms gesagt, bräuchten sie. Selber Quellcode.
Ich versuch erstmal das ganze flüssiger zu machen, ich häng mal mein Projekt an. Ich erwarte nicht, dass das jemand durchguckt. Aber vielleicht sieht ja jemand direkt auf Anhieb etwas, was auf garkeinen Fall sein darf. :P

[shmia]

Die Ursache für die schlechte Performance ist TListBox.Items.
Die Klasse ist zwar von TStrings abgeleitet, speichert seine Daten aber nicht selbst, sondern
per Windows Messages im darunterliegenden Control. Das Versenden von hundertausenden Messages braucht eben Zeit.
Abhilfe:
Daten in einer TStringList erzeugen und dann mit Assign auf die TListbox kopieren.

[Kuonrat]

Okay, danke für den Tipp. Werd eich beachten. Die Fehlerursache liegt bei der zeitmessung. Ich war so KLUK 'QueryPerformanceFrequency' zu benutzten statt GetTickCount. Das war die ultimative Performance Bremse. Jetzt erreiche ich endlich die Werte die ich haben möchte. :)