TTreeView komige Speedprobleme...

[DelTurbo]

Hi,
ich habe folgendes Problem. Ich habe ein kleines Programm gemacht was einen TTreeView füllt. Wenn ich das auf meinem "normalen" Arbeitsrechner laufen lasse, dauert es ~1 Minute.

Lasse ich das in einer VMWare auf dem selben rechner laufen, ist die dauer ~17 Sekunden.

Hier mal ein bissl eckdaten vom System.
CPU ist eine I5-760.
WinXP SP3
Delphi 7 mit mad und Indy10
Kayspersky 2010 Internet Security

Hat vielleicht jemand eine Idee wer oder was das füllen von einem TTreeView so verlangsamt?

Im moment bin ich an einem Laptop mit einer 1,6Mhz Pentuim M CPU. Er braucht ca. 57 Sekunden.

Vielen dank im voraus

[Bernhard Geyer]

Ich schmeiß mal folgende "Zauberzeilen" in den Ring:

Items.BeginUpdate;
Items.EndUpdate;

bzw. virtueller Modus

....

[rweinzierl]

Hallo

Wenn geschwindigkeit wichtig ist dann die Virtual Tree View Komponenten verwenden.

==> Mehr aufwand aber es lohnt sich.

mfg

Reinhold

[DelTurbo]

Hallo ihr zwei ;)

Beginupdate und EndUpdate ist drinne. Aber das war eigentlich nicht meine frage. Meine frage ist, wie kann es sein das es hier auf dem System 4x langsamer ist?

Hat dazu vielleicht jemand eine idee? Ich habe gestern abend noch auf dem Laptop Kaspersky aufgespielt. Der speed auf dem laptop hat sich nicht geändert.

Also den Virenscanner kann ich schonmal ausschliessen.

Auf diesem System hier wird auch keinerlei Software mal installiert und wieder deinstalliert. Wenn ich eine Soft testen möchte, dann mache ich das immer in einer Virtuellen. Dafür sind die ja da. Es sind auch keinerlei Spiele auf diesem System hier. Dafür ist ein 2. System auf einer 2. platte im System.

Hatte vielleicht schonmal jemand das gleiche prob?

[wicht]

Wieviele Items sind es denn? Hast du etwas Code zum zeigen, was das Hinzufügen angeht?

[DelTurbo]

Hi,
also es sind 54.279 Items. Hinzugefügt werden sie aus diesem Post. http://www.delphipraxis.net/1118455-post9.html Ich habe den link von Lannes genommen, der mir netterweise an dieser stelle geholfen hat.

Wobei ich denke das es egal ist ob ich 10.000 oder 100.000 Items hinzufüge. Und eigentlich sollte es doch auch egal sein wie. Da ich immer die gleiche .exe zum messen nehme. Oder irre ich mich???

Wenn ich mein "SpieleSystem" boote sind die in ~14 Sek. drinn. Mehr als 4x so schnell. Und das mit der gleichen .exe auf der gleichen Hardware.

[FredlFesl]

Ich mach das immer so, das ich die zu einem Knoten gehörenden Kinder erst dann lade, wenn man zum 1.Mal auf den [+]-Button klickt.
Sofern die 57.932 Einträge nicht alle in Level-0 enthalten sind, wird der Baum dann sofort, d.h. ohne Zeitverzögerung dargestellt.

Oder zeigst Du etwa alle 54.279 gleichzeitig an?

[DelTurbo]

Nein, es sind alles mind. level 1 einträge, bis auf einen. Der TTreeView wird auf einmal gefüllt. Ich lese die daten in einen TStringList ein (die dauer ist abgezogen) und fülle dann den TTreeView so wie in dem link beschrieben.

Ich habe nun auchmal versucht mit dem ProcessExplorer zu sehen warum das so ist. Aber es wird mir nur die .exe angezeigt die last macht.

Im moment bin ich kurz davor mein System neu zu machen. Weil es kann ja nicht an der "Füllart" liegen. Wenn das der fall wäre, dann wäre es überall langsam bzw. gleich schnell.

Das ist halt die sache die ich nicht verstehe. Warum ist es nur auf diesem System so langsam?

EDIT: Ich habe es grade auf einem anderen Laptop getestet. Da ist eine Uralte installation drauf. Das teil hat eine 1,5Ghz CPU und ist schneller als hier das System mit einem i5-760. Irgendwie verwirrt mich das alles.

[Bjoerk]

Probier' mal so, vielleicht bringt's ja was.

Delphi-Quellcode:

procedure GetNodeDirs(const ADirectory: String; const Tree: TTreeView; const Start: TTreeNode);

  function SlashSep(const Path, S: String): String;
  begin
    if AnsiLastChar(Path)^ <> '\' then
      Result:= Path+'\'+S
    else
      Result:= Path+S;
  end;

var
  SearchRec: TSearchRec;
  NewNode: TTreeNode;

begin
  if FindFirst(SlashSep(ADirectory, '*.*'), faDirectory, SearchRec) = 0 then
  try
    repeat
      if ((SearchRec.Attr and faDirectory) <> 0) then
        if ((SearchRec.Name <> '.') and (SearchRec.Name <> '..')) then
        begin
          NewNode:= Tree.Items.AddChild(Start, SearchRec.Name);
          GetNodeDirs(SlashSep(ADirectory, SearchRec.Name), Tree, NewNode);
        end;
    until FindNext(SearchRec) <> 0;
  finally
    Findclose(SearchRec);
  end;
end;


TreeView1.Items.BeginUpDate;  
TreeView1.Items.Clear;
GetNodeDirs('C:\', TreeView1, TreeView1.Items.AddChild(Nil, 'C:\'));
// TreeView1.AlphaSort;
TreeView1.Items.EndUpDate;

[DelTurbo]

Habe ich schon hinter mir. Da bremst eh die platte. Wenn man es 2x hintereinander laufen lässt, und er die sachen aus dem cache hohlt, habe ich das gleiche problem. Das füllen der TreeView ist wesentlich langsamer als auf anderen Systemen.

Ich glaube nicht das es ein Delphi problem ist. Ich denke es liegt am Windows selber. Blos weiss ich nicht was dort im eimer ist.

Deswegen fragte ich ja, ob das schonmal jemand hatte. Hätte ja sein können. Die hoffnung stirbt bekanntlich zuletzt.

[Luckie]

Was will der Benutzer mit 55.000 Tausend Einträgen? Und das sind alles Wurzeleinträge? Da scrollt man sich ja zu Tode, wenn man da was sucht.

[DelTurbo]

Zitat:

Zitat von Luckie (Beitrag 1119912)

Was will der Benutzer mit 55.000 Tausend Einträgen? Und das sind alles Wurzeleinträge? Da scrollt man sich ja zu Tode, wenn man da was sucht.

Sorry, aber das ist doch egal. Auch wenn 1.000.000 einträge drinn wären. Fakt ist, das "mein" System mind. 4x langsamer ist und ich gerne wüsste ob das schonmal jemand hatte.

[FredlFesl]

Ich glaube, Du hast begriffen, das 50.000 Einträge auf einmal anzuzeigen ziemlich "blöd" ist.

Zitat:

Zitat von DelTurbo (Beitrag 1119913)

Fakt ist, das "mein" System mind. 4x langsamer ist und ich gerne wüsste ob das schonmal jemand hatte.

Also, das es auf einem System langsamer ist, als auf dem Anderen: Nein.
Das die TTreeView sowieso unglaublich lahm ist: JA!

[DelTurbo]

Zitat:

Zitat von FredlFesl (Beitrag 1119922)

Ich glaube, Du hast begriffen, das 50.000 Einträge auf einmal anzuzeigen ziemlich "blöd" ist.

Ja klar. Aber darum geht es ja nicht. Ich frage mich nur, was kann das sein, das es hier langsamer ist als auf anderen Systemen.

Kann es an einer "falschen" DLL liegen die mit irgendwas installiert wurde? Oder Registry einträge die im eimer sind?

Ich habe noch nie irgendwelche RegCleaner oder sowas laufen lassen müssen. Vielleicht wäre das ein versuch wert. Und wenn ja, welchen würdet ihr nehmen?

[FredlFesl]

Ist schon merkwürdig. Da das TTreeView jedoch ein Windowscontrol ist, wissen wir nicht, wie die letztendlich verwaltet und gezeichnet werden.

[DelTurbo]

Ich habe mir das mal mit dem VirtualTree angesehen. 1.000.000 Root einträge dauern 63ms. 1.000.000 Childs 153ms.

Also auf VirtualTree werde ich das auf jeden fall umschreiben.

Trotzdem bleibt ein blöder beigeschmack. Warum ist das so wie es ist? Warum nur auf diesem System?

[Luckie]

Also wenn du die Anzahl der zu erst erstellten Einträge reduzierst, solltest du auch auf dem langsamen Rechner gute Zeiten bekommen. Und warum es langsamer ist? Andere Hardware (weniger RAM, ...) oder es laufen einfach mehr Prozesse, so dass dein Prozess weniger Rechenzeit bekommt. Da kann es ein paar Gründe geben. Aber was willst du bei einem Kunden/Benutzer machen? Willst du ihm sagen, er soll Windows neu installieren und keine weiteren Programm außer deinem?

Also optimiere das ganze, so dass erst mal nur die wirklich benötigten Einträge gemacht werden und die weiteren erst bei Bedarf.

[mschaefer]

Zitat:

Zitat von DelTurbo (Beitrag 1119868)

Hi,
Wenn ich das auf meinem "normalen" Arbeitsrechner laufen lasse, dauert es ~1 Minute.

Lasse ich das in einer VMWare auf dem selben rechner laufen, ist die dauer ~17 Sekunden.

Möglicherweise war das Sonntagsbrötchen besonders helle, denn irgendwie komme ich zu dem Schluß, dass es sich hier um kein Speedproblem des TreeView selbst handeln kann.

Das Problem könnte in der Datenquelle liegen. zum Beispiel wenn Du eine Directorystruktur einliest könnte ein bremsendes Laufwerk dabei sein (Probleme bei der Master/Slave-Konfiguration, falscher Treiber, Steckerkontaktprobleme). In einer VM ist dieses optimiert und daher schnell.

und jetzt gehe ich mal das Croissant testen...

Grüße in die Runde

[DelTurbo]

Zitat:

Zitat von Luckie (Beitrag 1119956)

Also wenn du die Anzahl der zu erst erstellten Einträge reduzierst, solltest du auch auf dem langsamen Rechner gute Zeiten bekommen. Und warum es langsamer ist? Andere Hardware (weniger RAM, ...) oder es laufen einfach mehr Prozesse, so dass dein Prozess weniger Rechenzeit bekommt. Da kann es ein paar Gründe geben. Aber was willst du bei einem Kunden/Benutzer machen? Willst du ihm sagen, er soll Windows neu installieren und keine weiteren Programm außer deinem?

Also optimiere das ganze, so dass erst mal nur die wirklich benötigten Einträge gemacht werden und die weiteren erst bei Bedarf.

Nochmal sorry. Aber würdest du mal richtig lesen, dann würdest du feststellen das ich das auch auf der gleichen Hardware getestet habe (Post #6). Ich habe es hier auf 6 Rechnern getestet. Angefangen vom 1,5Ghz bis zum dem hier (i5-760). Dieses Speedprob tritt nur auf einem BetriebsSystem auf. Es kann sein das es noch bei anderen objekten auftritt. Das weiß ich natürlich nicht. Es ist mir halt nun beim TreeView aufgefallen.

Zitat:

Zitat von mschaefer (Beitrag 1119960)

Das Problem könnte in der Datenquelle liegen. zum Beispiel wenn Du eine Directorystruktur einliest könnte ein bremsendes Laufwerk dabei sein (Probleme bei der Master/Slave-Konfiguration, falscher Treiber, Steckerkontaktprobleme). In einer VM ist dieses optimiert und daher schnell.

Mir ist im moment unerklärlich wie du sowas schreiben kannst. Im Thread steht das die sachen aus dem RAM (TStringlist, Post #8) gefüllt werden. Ich habe auch geschrieben das die zeit zum laden der daten abgezogen wurde.

Da anscheinden jeder nur ein Post liest, und meint antworten zu müssen ist der Thread hier total versaut. Es wird sich wohl kaum noch jemand die mühe machen 19 Posts zu lesen, wovon die meisten am eigentlichen problem vorbeigehen. Ich glaube der einzige hier der bissl begriffen hat worum es geht ist FredlFesl (Post #13).

Eigentlich sehr sehr schade.......

[Alaitoc]

Eigentlich wurden hier genug Vorschläge gebracht woran es liegen könnte, wobei es wahrscheinlich wirklich nicht an der Hardware liegt oder direkt an der Komponente TTreeview, sondern einfach an den unterschiedlichen Prozessen die im Hintergrund laufen, Dienste die ebenfalls behindern könnten oder sonstige unterschiede beim Betriebssystem, wie vll. sogar Servicepacks oder sonstige Updates, wer weiß?

Zitat:

Zitat:

Zitat von Luckie:
Also wenn du die Anzahl der zu erst erstellten Einträge reduzierst, solltest du auch auf dem langsamen Rechner gute Zeiten bekommen. Und warum es langsamer ist? Andere Hardware (weniger RAM, ...) oder es laufen einfach mehr Prozesse, so dass dein Prozess weniger Rechenzeit bekommt. Da kann es ein paar Gründe geben. Aber was willst du bei einem Kunden/Benutzer machen? Willst du ihm sagen, er soll Windows neu installieren und keine weiteren Programm außer deinem?

Also optimiere das ganze, so dass erst mal nur die wirklich benötigten Einträge gemacht werden und die weiteren erst bei Bedarf.

Nochmal sorry. Aber würdest du mal richtig lesen, dann würdest du feststellen das ich das auch auf der gleichen Hardware getestet habe (Post #6). Ich habe es hier auf 6 Rechnern getestet. Angefangen vom 1,5Ghz bis zum dem hier (i5-760). Dieses Speedprob tritt nur auf einem BetriebsSystem auf. Es kann sein das es noch bei anderen objekten auftritt. Das weiß ich natürlich nicht. Es ist mir halt nun beim TreeView aufgefallen.

Er hat zum Beispiel nicht nur die Hardware genannt, zusätzlich Prozesse oder sonstige Software, bzw. Fehler am Betriebssystem.

Ändere es doch einfach auf VirtualTreeview um, wenn es dann auf deinen schnellen Testrechnern in einer Sekunde läuft und auf dem langsamen Rechner ein paar Sekunden mehr dauert, wirst du dich auch nicht mehr mit dem Problem auseinandersetzen müssen.

Zitat:

Da anscheinden jeder nur ein Post liest, und meint antworten zu müssen ist der Thread hier total versaut. Es wird sich wohl kaum noch jemand die mühe machen 19 Posts zu lesen, wovon die meisten am eigentlichen problem vorbeigehen. Ich glaube der einzige hier der bissl begriffen hat worum es geht ist FredlFesl (Post #13).

Eigentlich sehr sehr schade.......

Ich behaupte jetzt einfach mal alle relevanten Informationen aus dem Thread herausgezogen zu haben, jedoch hätte ich diese Nachricht wohl am Anfang des Threads gelesen...hätte ich direkt aufgehört mich mit dem Thema auch nur ein wenig auseinanderzusetzen.
Wenn jemand wirklich den ganzen Thread nicht gelesen hat, kann man ihn einfach höflich darauf hinweisen was er übersehen hat.

MfG Alaitoc

[DelTurbo]

Zitat:

Zitat von Alaitoc (Beitrag 1119985)

wie vll. sogar Servicepacks oder sonstige Updates, wer weiß?

Genau darum geht es. Ich dachte das sowas schonmal einer hatte. Dann hätte ich gezielt suchen können. Es hat ja im grunde nichts mit dem eigentlichen TreeView zu tun. Es ist mir da halt nur aufgefallen. Es kann ja sein das noch andere sachen betroffen sind.

Ich hätte auf Kaspersky getippt. Aber der ist das nicht.

[mschaefer]

Sachte - erstmal ´nen Tee:

Du gibtst eine VM Zeit an von 17s und eine VM-Host-Zeit von knapp 1 min an und fragst danach was das Füllen so verlangsamt.
Wenn die VM schneller läuft alsder VM-Host, dann ist das kein TreeView Problem. Deutet auf ein heftiges Systemproblem, Prozesse, Treiber, Hardware, hin (oder Zahlentausch). Du hast selbst geschreiben, dass Du das eventuell neu aufsetzen willst (gute Idee).

Die technsichen Macken, aus #18, schlagen zum Teil auch beim Caching zu und dann sind Hardwareproblem auch da die Ursache, wenn es nur aus der StringList kommt. Würde zum Speedtest den Treeview in einer For-Next-Schleife mit dem gleichen String füllen.

Mein Fazit:

- Wenn die Zahlen aus #1 stimmen ist, solltest Du das System neu aufsetzen.
- klären was wirklich angezeigt werden muß.
- VirtualTreeView nehmen

Schönen Sonntag noch!

[Bjoerk]

Ich habe mal zum Vergleich eine ListBox getestet und war doch einigermaßen erstaunt, daß das TreeView (ohne Images) genaus so schnell ist wie diese. Scheint ein Aberglaube zu sein, daß TreeView stinklangsam ist. Auf jeden Fall auch viel schneller als ein Memo, aber das denke ich, ist klar.

Delphi-Quellcode:

procedure GetDirs(const Start: String; const SL: TStrings);
var
  S: TSearchRec;
  P: string;
  R: integer;
begin
  R:= FindFirst(Start+'*.*', faDirectory, S);
  while R = 0 do
  begin
    if ((S.Attr and faDirectory) <> 0) then
      if ((S.Name <> '.') and (S.Name <> '..')) then
      begin
        P:= Start+S.Name+'\';
        SL.Add(P);
        GetDirs(P, SL);
      end;
    R:= FindNext(S);
  end;
  Findclose(S);
end;


procedure GetNodeDirs(const ADirectory: String; var ATree: TTreeView; const Start: TTreeNode);
  function SlashSep(const Path, S: String): String;
  begin
    if AnsiLastChar(Path)^ <> '\' then
      Result:= Path+'\'+S
    else
      Result:= Path+S;
  end;
var
  S: TSearchRec;
  N: TTreeNode;
  R: integer;
begin
  R:= FindFirst(SlashSep(ADirectory, '*.*'), faDirectory, S);
  while R = 0 do
  begin
    if ((S.Attr and faDirectory) <> 0) then
      if ((S.Name <> '.') and (S.Name <> '..')) then
      begin
        N:= ATree.Items.AddChild(Start, S.Name);
        GetNodeDirs(SlashSep(ADirectory, S.Name), ATree, N);
      end;
    R:= FindNext(S);
  end;
  Findclose(S);
end;


procedure TForm1.Button1Click(Sender: TObject); // ListBox
var
  fPath: string;
  fTime: Cardinal;
begin
  fPath:= 'C:\';
  ListBox1.Items.Clear;

  fTime:= GetTickCount;
  ListBox1.Items.BeginUpdate;
  GetDirs(fPath, ListBox1.Items);
  ListBox1.Items.EndUpdate;

  Label1.Caption:= IntToStr(GetTickCount-fTime);
end;


procedure TForm1.Button2Click(Sender: TObject); // TreeView
var
  fPath: string;
  fTime: Cardinal;
begin
  fPath:= 'C:\';
  TreeView1.Items.Clear;

  fTime:= GetTickCount;
  TreeView1.Items.BeginUpDate;
  GetNodeDirs(fPath, TreeView1, TreeView1.Items.AddChild(Nil, fPath));
  TreeView1.Items.EndUpDate;

  Label2.Caption:= IntToStr(GetTickCount-fTime);
end;


procedure TForm1.Button3Click(Sender: TObject); // StringList
var
  fPath: string;
  fTime: Cardinal;
  SL: TStringList;
begin
  fPath:= 'C:\';
  SL:= TStringList.Create;

  fTime:= GetTickCount;
  GetDirs(fPath, SL);
  Label3.Caption:= IntToStr(GetTickCount-fTime)+' ('+IntToStr(SL.Count)+')';

  SL.Free;
end;

[Alaitoc]

Sobald man bei Delphi mehrere Einträge für ne TreeView hat, sollte man lieber auf die Alternative VirtualTreeview wechseln. Keine Ahnung wie sie im Vergleich zu anderen Standard-Delphi Komponenten steht, jedoch ist sie im Vergleich zu der VirtualTreeview Alternative deutlich langsamer.

Das hatte ich ja schon bei meiner eigenen TTreeview-Dropdown-Komponente gemerkt (welche auf TTreeview basiert) dass es da relativ schnell zu Performance Einbußen kommt.

Falls du wirklich die Ursache herausfinden willst kannste ja mal alles nach und nach von deinem Rechner werfen *g*

MfG Alaitoc

Edith sagt: Ebenfalls einen schönen Sonntag ;)

[wicht]

Auch wenn der Thread jetzt vielleicht "vorbei" ist möchte ich noch meine Meinung schreiben. Ersteinmal muss ich mschaefer beipflichten - wenn etwas auf ein und dem selben PC in der VM schneller läuft, als auf der realen Hardware, kann irgendetwas nicht stimmen. Vielleicht wirklich neu aufsetzen.
Dazu kommt noch, dass ich das TTreeView nur bei Dingen einsetze, die nur wenige Einträge haben. Es ist nicht nur langsam, teilweise gibt es auch ein lustiges Flackern, wenn man die Maus über die Einträge bewegt. Ab und an verschwinden auch die Header (Spalten-Überschriften). TTreeView benutze ich selber nur für Darstellungen, die wenige Einträge haben und nicht die ganze Zeit sichtbar sind (wegen den Flackereffekten - z.B. nutze ich TTreeView/TListView in Einstellungsfenstern) - ansonsten setze ich an allen anderen Stellen auf TVirtualTreeView, das ist einfach DIE Komponente, um Listen oder Bäume darzustellen. Man muss sich zwar etwas einarbeiten, aber dafür bietet die Komponente fast unzählbare Möglichkeiten.
Danke, Herr Mike Lischke!

[ChrisE]

Hallo,

vielleicht hast du schon eine Lösung des Problems, dennoch habe ich ein zwei Anmerkungen, die ich hier auch noch anbringen möchte:

- Deine VM hat u.U. nicht die selbe Anzahl an Items wie Dein Hostsystem.

Zitat:

Zitat von DelTurbo (Beitrag 1119987)

Wobei ich denke das es egal ist ob ich 10.000 oder 100.000 Items hinzufüge

- Es dauert sehr wohl länger 100.000 Einträge zu erzeugen gegenüber 10.000 (nämlich im einfachsten Fall genau um den Faktor 10) - da der Code der zum hinzufügen ausgeführt werden muss ja 10 mal häufiger durchlaufen wird.

Bezogen auf Deine Frage, warum es langsamer ist auf System A zu B würde ich somit das naheliegenste Wählen: Ich denke tatsächlich, dass der Geschwindigkeitsunterschied daher kommt, dass die gesamte Anzahl an Items sich in Host und VM unterscheiden.

Gruß, Chris

BTW:

Zitat:

Zitat von DelTurbo (Beitrag 1119987)

Und eigentlich sollte es doch auch egal sein wie. Da ich immer die gleiche .exe zum messen nehme. Oder irre ich mich???

Das es absolut betrachtet Egal ist wie man einfügt glaube ich nicht spricht z.B. der Unterschied mit BeginUpdate und ohne. Relativ betrachtet - sprich immer die selbe exe - hast du sicher recht. Allerdings ist hier auch die Frage, wie stark das OS "Programmiereigenarten" kappselt / verbessert / verschlechtert. Ein XP geht mit machen Dingen sehr wohl anders um als z.B. ein Windows 7. Die selbe EXE kann sich dann auf zwei Systemen unterschiedlich verhalten und unterschiedliche Performance zeigen.

[Luckie]

Zitat:

Zitat von DelTurbo (Beitrag 1119970)

Zitat:

Zitat von Luckie (Beitrag 1119956)

Also wenn du die Anzahl der zu erst erstellten Einträge reduzierst, solltest du auch auf dem langsamen Rechner gute Zeiten bekommen. Und warum es langsamer ist? Andere Hardware (weniger RAM, ...) oder es laufen einfach mehr Prozesse, so dass dein Prozess weniger Rechenzeit bekommt. Da kann es ein paar Gründe geben. Aber was willst du bei einem Kunden/Benutzer machen? Willst du ihm sagen, er soll Windows neu installieren und keine weiteren Programm außer deinem?

Also optimiere das ganze, so dass erst mal nur die wirklich benötigten Einträge gemacht werden und die weiteren erst bei Bedarf.

Nochmal sorry. Aber würdest du mal richtig lesen, dann würdest du feststellen das ich das auch auf der gleichen Hardware getestet habe (Post #6).

Im ersten Posting redest du aber noch von einer VM:

Zitat:

Lasse ich das in einer VMWare auf dem selben rechner laufen, ist die dauer ~17 Sekunden.

Und das ist ein zweiter Rechner. Oder hat die VM zum Beispiel genauso viel Arbeitsspeicher wie das Hostsystem? In der VM ist ein zweites Windows installiert. Ich glaube kaum, dass dieses exakt identisch ist mit der installierten Software, laufenden Diensten, Autorun-Programmen wie das Windows vom Hostsystem. Also haben wir es defakto mit zwei unterschiedlichen Rechnern zu tun und zwar was so wohl die Hardware als auch die Software angeht.

[DelTurbo]

Hmm, ich fang einfach mal der reihe nach zu antworten.

Zitat:

Zitat von mschaefer (Beitrag 1119990)

Die technsichen Macken, aus #18, schlagen zum Teil auch beim Caching zu und dann sind Hardwareproblem auch da die Ursache, wenn es nur aus der StringList kommt. Würde zum Speedtest den Treeview in einer For-Next-Schleife mit dem gleichen String füllen.

Wenn du Post #6 gelesen hättest würdest du nicht sagen das es ein Hardware prob ist.

Zitat:

Zitat von wicht (Beitrag 1120006)

Auch wenn der Thread jetzt vielleicht "vorbei" ist möchte ich noch meine Meinung schreiben. Ersteinmal muss ich mschaefer beipflichten - wenn etwas auf ein und dem selben PC in der VM schneller läuft, als auf der realen Hardware, kann irgendetwas nicht stimmen.

Richtig. Aber nicht Hardwareseitig sondern am Windows selber. Ich wollte auch nur wissen ob das schonmal einer hatte.

Zitat:

Zitat von ChrisE (Beitrag 1120071)

- Deine VM hat u.U. nicht die selbe Anzahl an Items wie Dein Hostsystem.

Logischerweise werde immer die gleichen daten gelesen. Wie will man sowas sonst testen? Auf einem System mit 2 einträgen arbeiten, auf dem anderen mit 100.000 und dann sagen "Hui, da stimmt aber was nicht".

Zitat:

Zitat von ChrisE (Beitrag 1120071)

- Es dauert sehr wohl länger 100.000 Einträge zu erzeugen gegenüber 10.000 (nämlich im einfachsten Fall genau um den Faktor 10) - da der Code der zum hinzufügen ausgeführt werden muss ja 10 mal häufiger durchlaufen wird.

[ironie_on] Das wusste ich garnicht. [ironie_off]

Zitat:

Zitat von Luckie (Beitrag 1120072)

Im ersten Posting redest du aber noch von einer VM:

Zitat:

Lasse ich das in einer VMWare auf dem selben rechner laufen, ist die dauer ~17 Sekunden.

Und das ist ein zweiter Rechner. Oder hat die VM zum Beispiel genauso viel Arbeitsspeicher wie das Hostsystem? In der VM ist ein zweites Windows installiert. Ich glaube kaum, dass dieses exakt identisch ist mit der installierten Software, laufenden Diensten, Autorun-Programmen wie das Windows vom Hostsystem. Also haben wir es defakto mit zwei unterschiedlichen Rechnern zu tun und zwar was so wohl die Hardware als auch die Software angeht.

Das mit der VM war ein Beispiel. Zumal eine VM langsamer ist als der Host. Jenachdem was man macht. Logischerweise. Die muss z.b. die NIC, IDE, SCSI usw. emulieren.
Leider muss ich auch dich auf Post #6 verweisen.

Nochmal, es ging im grunde "nur" um die frage ob sowas schonmal jemand hatte. Warum ich hier in dem Forum frage, und nicht woanders? Weil ich dachte, hier braucht man nicht zu erklären was ein TTreeView ist, und was der macht.

In Delphifragen wurde mir hier auch immer sehr nett und schnell geholfen. Auch wenn es mal eine "dumme" frage war, weil ich den Wald vor lauter Bäumen nicht sah.

Trotzdem danke ich allen die versucht haben zu helfen. :thumb:

Auch wenn das eigentliche Thema verfehlt wurde. Sowas kann einfach passieren. Wir sind alle "nur" menschen.

[ChrisE]

Zitat:

Zitat von DelTurbo (Beitrag 1120098)

Zitat:

Zitat von ChrisE (Beitrag 1120071)

- Es dauert sehr wohl länger 100.000 Einträge zu erzeugen gegenüber 10.000 (nämlich im einfachsten Fall genau um den Faktor 10) - da der Code der zum hinzufügen ausgeführt werden muss ja 10 mal häufiger durchlaufen wird.

[ironie_on] Das wusste ich garnicht. [ironie_off]

;-) Danke dir für die Ironie - aber vielleicht sollte ich Dich auf Deine Posts verweisen: In #6 behauptests du, dass genau das egal ist. Und da du nie gepostet hast dass die Daten tatsächlich absolut Identisch sind, ist das auch nicht logisch - sondern eher eine mögliche Fehlerquelle (siehe folgenden Satz)

Zitat:

Zitat von DelTurbo (Beitrag 1120098)

Logischerweise werde immer die gleichen daten gelesen. Wie will man sowas sonst testen? Auf einem System mit 2 einträgen arbeiten, auf dem anderen mit 100.000 und dann sagen "Hui, da stimmt aber was nicht".

Die "Themaverfehlung" Deiner Helfer hier hat sicher manchmal etwas mit überlesen zu tun, aber man sollte auch so weit reflektieren, ob die Helfer die vollständigen Informationen haben um helfen zu können. Niemand weiß genau was Du als Fragender als Logisch voraussetzt und was nicht. Es wird nicht versucht irgendwelche Glaskugelposts zu produzieren und Dir statt dessen zu helfen. Damit wird etwas im trüben gefischt und vielleicht tatsächlich am Thema vorbei gepsorchen - aber das ist meines Erachtens nicht ausschließlich das Versäumnis der Helfer.

In einer Sache stimme ich Dir aber dennoch voll und ganz zu

Zitat:

Zitat von DelTurbo (Beitrag 1120098)

Wir sind alle "nur" menschen.

Gruß, Chris

[DelTurbo]

Zitat:

Zitat von DelTurbo (Beitrag 1119897)

Hi,
also es sind 54.279 Items. Hinzugefügt werden sie aus diesem Post. http://www.delphipraxis.net/1118455-post9.html Ich habe den link von Lannes genommen, der mir netterweise an dieser stelle geholfen hat.

Wobei ich denke das es egal ist ob ich 10.000 oder 100.000 Items hinzufüge. Und eigentlich sollte es doch auch egal sein wie. Da ich immer die gleiche .exe zum messen nehme. Oder irre ich mich???

Wenn ich mein "SpieleSystem" boote sind die in ~14 Sek. drinn. Mehr als 4x so schnell. Und das mit der gleichen .exe auf der gleichen Hardware.

huhu, les dochmal genau. Da steht es werden 54.279 Items eingetragen. Und das es auf dem System 4x langsamer ist. Es wäre auch bei 1.000.000 4x langsamer. Aber ich gebe zu, der mittlere satz ist nicht gut formuliert. Da hätte stehen müssen, das ich die gleiche .exe und die gleichen daten nehme. Aber das hatte ich wohl vorraus gesetzt das es logisch ist das ich immer die gleichen daten nehme.

Das das hier soooo schief gelaufen ist, nehme ich keinem übel. Ich glaube das habe ich in meinem letzten Post deutlich zum ausdruck gebracht.

[ChrisE]

Zitat:

Zitat von DelTurbo (Beitrag 1120109)

huhu, les dochmal genau

Genau diese Art von Aussagen macht es für mich schwer zu glauben, dass du konstruktiv arbeiten möchtest. Soetwas stößt meines Erachtens nach den Leuten nur vor den Kopf.
Es gab wohl auch den einen oder andere, der mache Aussagen etwas "Stramm" empfandt:

Zitat:

Zitat von mschaefer (Beitrag 1119990)

Sachte - erstmal ´nen Tee

Ich denke, ich brauche Dir nichts über Umgangsformen erklären - du weißt genau wovon ich rede. Und ein "huhu, les doch mal genau" - wäre wohl besser ein "Oh, da hast du mich falsch verstanden, eigentlich meinte ich es so wie man hier im kompletten Post sehen kann, dass..."

Ich meine das wirklich nicht persönlich - aber ich denke doch, dass man in einem so tollen Forum mit so vielen fähigen Leuten froh sein kann über die Hilfe. Und dass sollte man auch in seinen Formulierungen lesebar zeigen.

Es ist wirklich nicht böse gemeint, sondern die hoffentlich richtig formulierte rein subjektive Sichtweise :-)

Gruß, Chris

[DelTurbo]

Sorry, aber ich weiss wirklich nicht was du in ein "huhu" reininterpretierst. Hätte ich "Hallo" oder "sehr geehrte damen und herren" schreiben sollen?

Wenn du ein nett gemeintes "huhu" falsch verstehst, dann weiss ich auchnicht. Und ich glaube nicht das ich hier einen fertig gemacht habe. Im gegenteil.

Zitat:

Zitat von DelTurbo (Beitrag 1120098)

In Delphifragen wurde mir hier auch immer sehr nett und schnell geholfen. Auch wenn es mal eine "dumme" frage war, weil ich den Wald vor lauter Bäumen nicht sah.

Trotzdem danke ich allen die versucht haben zu helfen. :thumb:

Auch wenn das eigentliche Thema verfehlt wurde. Sowas kann einfach passieren. Wir sind alle "nur" menschen.

Eigentlich dachte ich das damit die sache durch wäre. Das einzige was ich tun werde, ist, dich nichtmehr mit "huhu" zu grüssen.

Wäre schön wenn das nun mal einer zumacht. Weil es wird nur noch OffTopic geschrieben. Oder das ding verschieben und auflassen.

[mschaefer]

:-)

[Luckie]

Und ich bin dafür, dass ihr einfach keine Beiträge mehr schreibt, wenn ihr nichts mehr zum ursprünglichen Thema zu sagen habt.

[jaenicke]

Zum Unterschied VM <--> Host:
Die VM puffert vielleicht schlicht die Daten für die Grafikkarte.

[DelTurbo]

Schlusswort: Ich habe das nun alles auf VirtualStringTree (VST) unmgestellt.

WAU ist das schnell. Da hatte jemand genau die richtige idee. Die daten nur hohlen wenn sie auch gebraucht werden. Ich glaube mit dem normalen TreeView werde ich nie mehr arbeiten. :-D

Gruss und danke an alle die versucht haben zu helfen und mir den tipp mit VST gaben... :thumb: