Autor |
Beitrag |
retnyg
Beiträge: 2754
SNES, GB, GBA, CPC, A500, 486/66, P4/3.0HT: NintendOS, AmigaOS, DoS
Delphi 5, Delphi 7
|
Verfasst: So 23.10.05 18:20
Heiko hat folgendes geschrieben: | Mhm, du scheinst immer irgendwelche Fälle zu haben, die ich nicht teste . |
eigentlich ziemlich naheliegend
Heiko hat folgendes geschrieben: | @Suchbegriffsübergabe: Könnte man umgestalten, allerdings würde ich dann das | nehmen . |
damit brichst du aber mit der syntax, die windows-weit von suchprogrammen verwendet wird
Heiko hat folgendes geschrieben: | @globale Variable für die Rückgabe: Warum disqualifiziert die sich dann dort gleich? Man braucht ja nur den Wert immer in eine andere Variable speichern, wodurch dann paralleles Suchen und auswerten der einzelnen Ergebnisse möglich wäre. Das gleiche würde man ja machen, wenn man parallel Suchen und Auswerten will, wenn man das Array als Parameter übergibt . |
falsch: bei meiner variante kann ich 2 versch. threads mit 2 versch. variablen laufen lassen, ohne dass die sich gegenseitig im speicher rumpfuschen
Heiko hat folgendes geschrieben: | @Testen: Wie gesagt ich nutzte eigentlich nur v1.0, da ich nur die Endungen brauche, und da gibt es keine Probleme mit Mehrfachfilterung. Es kann eigentlihc nur daran leigen, das ich wahrscheinlich den Filter nur einmal rüberjage anstatt mehrmals . |
tja, wenn du hier eine unit reinstellst solltest du sie schon testen, auch wenn du sie selber nicht verwendest.
sonst könntest du gleich folgende prozedur hier anbieten:
Delphi-Quelltext 1: 2: 3: 4:
| procedure findFiles(root, mask: string); asm nop end; |
das resultat ist (oder war) in einigen fällen gleich wie bei dir, aber um einiges schneller
_________________ es gibt leute, die sind genetisch nicht zum programmieren geschaffen.
in der regel haben diese leute die regel...
|
|
Heiko
Beiträge: 3169
Erhaltene Danke: 11
|
Verfasst: So 23.10.05 18:32
retnyg hat folgendes geschrieben: | Heiko hat folgendes geschrieben: | Mhm, du scheinst immer irgendwelche Fälle zu haben, die ich nicht teste . |
eigentlich ziemlich naheliegend
Heiko hat folgendes geschrieben: | @Suchbegriffsübergabe: Könnte man umgestalten, allerdings würde ich dann das | nehmen . | damit brichst du aber mit der syntax, die windows-weit von suchprogrammen verwendet wird |
Mhm, denn kenne ich nicht, den mir ist noch kein solches Verfahren aufgefallen wo es so ist. Ich wollte den Filter so aufbauen wie bei einem OpenDialog etc. Aber wenn du sagst das es Standard ist werde ich mich dem Standard anschließen .
retnyg hat folgendes geschrieben: | Heiko hat folgendes geschrieben: | @globale Variable für die Rückgabe: Warum disqualifiziert die sich dann dort gleich? Man braucht ja nur den Wert immer in eine andere Variable speichern, wodurch dann paralleles Suchen und auswerten der einzelnen Ergebnisse möglich wäre. Das gleiche würde man ja machen, wenn man parallel Suchen und Auswerten will, wenn man das Array als Parameter übergibt . |
falsch: bei meiner variante kann ich 2 versch. threads mit 2 versch. variablen laufen lassen, ohne dass die sich gegenseitig im speicher rumpfuschen |
Jetzt ist mir klar was du meinst . Wobei eine parallele Suche sowieso nix bringt, da eine Festplatte ja davon nicht schneller wird und nur der Lesekopf der Festplatte dauernd sich hin und her bewegen muss, wodurch die lesegeschwindigkeit sich verringert . Außerdem braucht man das ja eigentlich nicht durch den Mehrfachfilter .
retnyg hat folgendes geschrieben: | Heiko hat folgendes geschrieben: | @Testen: Wie gesagt ich nutzte eigentlich nur v1.0, da ich nur die Endungen brauche, und da gibt es keine Probleme mit Mehrfachfilterung. Es kann eigentlihc nur daran leigen, das ich wahrscheinlich den Filter nur einmal rüberjage anstatt mehrmals . |
tja, wenn du hier eine unit reinstellst solltest du sie schon testen, auch wenn du sie selber nicht verwendest. |
Mhm, ich teste die schon, aber nicht mit allen Möglichkeiten die es gibt Ich habe die Unit immer nur mit einem Filter getestet, da ich immer gleich die Performance mit der driveTools verglichen habe und ich da weiß, das die DT bei Suche mehrerer Dateien langsamer ist .
retnyg hat folgendes geschrieben: | sonst könntest du gleich folgende prozedur hier anbieten:
Delphi-Quelltext 1: 2: 3: 4:
| procedure findFiles(root, mask: string); asm nop end; |
as resultat ist (oder war) in einigen fällen gleich wie bei dir, aber um einiges schneller |
Stimmt, die Variante wäre schneller .
Hast du jetzt eigentlich mal die Performance zwischen deiner und meiner jetzt funktionierenden Verglichen?
|
|
retnyg
Beiträge: 2754
SNES, GB, GBA, CPC, A500, 486/66, P4/3.0HT: NintendOS, AmigaOS, DoS
Delphi 5, Delphi 7
|
Verfasst: So 23.10.05 20:30
Heiko hat folgendes geschrieben: |
Mhm, denn kenne ich nicht, den mir ist noch kein solches Verfahren aufgefallen wo es so ist. Ich wollte den Filter so aufbauen wie bei einem OpenDialog etc. Aber wenn du sagst das es Standard ist werde ich mich dem Standard anschließen . |
musst nur mal im explorer nach *.jpg; *.jpeg; *.gif suchen
oder in deinem mailprogramm nach hallo; heiko
Heiko hat folgendes geschrieben: | Jetzt ist mir klar was du meinst . Wobei eine parallele Suche sowieso nix bringt, da eine Festplatte ja davon nicht schneller wird und nur der Lesekopf der Festplatte dauernd sich hin und her bewegen muss, wodurch die lesegeschwindigkeit sich verringert . Außerdem braucht man das ja eigentlich nicht durch den Mehrfachfilter . |
ed gibt auch leute, die besitzen mehr als eine festplatte
Heiko hat folgendes geschrieben: | Hast du jetzt eigentlich mal die Performance zwischen deiner und meiner jetzt funktionierenden Verglichen? |
das überlasse ich dir und dem publikum: siehe anhang
da drin ist meine unit, ein testprogramm, sowie deine und luckies unit
Einloggen, um Attachments anzusehen!
_________________ es gibt leute, die sind genetisch nicht zum programmieren geschaffen.
in der regel haben diese leute die regel...
|
|
Luckie
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: So 23.10.05 20:57
retnyg hat folgendes geschrieben: |
da drin ist meine unit, ein testprogramm, sowie deine und luckies unit |
Das ist ja immer noch die alte. Ich habe doch schon daraufhingewiesen, dass es eine neue gibt.
Und mach mal die ganzen Warnungen und Hinweise aus dem Quellcode raus, das sieht ja schrecklich aus.
|
|
Heiko
Beiträge: 3169
Erhaltene Danke: 11
|
Verfasst: Mo 24.10.05 07:55
So, ich habe mal in meinem Vergleichsprojekt die retFileSearch (die in dem einen Anhang dabei war) und die mpuDriveTools von Luckies Seite eingebaut:
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:
| unit Unit1;
interface
uses Windows, SysUtils, Forms, Dialogs, StdCtrls, Classes, Controls;
type TForm1 = class(TForm) Button4: TButton; procedure Button4Click(Sender: TObject); private public end;
var Form1: TForm1;
implementation uses mpuDriveTools, SearchTool, retFileSearch; {$R *.dfm}
procedure TForm1.Button4Click(Sender: TObject); var i: Integer; Zeit1, Zeit2, Zeit3, StartZeit: Cardinal; ST: TStringArray; FS: TArray; FindFiles: TFindFiles; Found: Integer; begin SetLength(ST, 1); ST[0]:='*.MP3'; FindFiles:=TFindFiles.Create(Form1.Handle, 'C:\', '*.MP3', true, false); for i:=0 to 1 do begin SearchTool.SearchFiles('C:\', ST, true); FindFiles.Init; FindFiles.FindFiles; Found:=retfilesearch.FindAllFiles('C:\', '*.MP3', FS, nil, true, false, true); end; Zeit1:=0; Zeit2:=0; Zeit3:=0; for i:=0 to 1 do begin StartZeit:=GetCurrentTime; SearchTool.SearchFiles('C:\', ST, true); inc(Zeit1, GetCurrentTime-StartZeit);
StartZeit:=GetCurrentTime; FindFiles.Init; FindFiles.FindFiles; inc(Zeit2, GetCurrentTime-StartZeit);
StartZeit:=GetCurrentTime; Found:=retfilesearch.FindAllFiles('C:\', '*.MP3', FS, nil, true, false, true); inc(Zeit3, GetCurrentTime-StartZeit); end; ShowMessage('ST: '+IntToStr(Zeit1 div 2)+' ms'+#13+ 'gefundene Dateien: '+IntToStr(SearchTool.cntFoundFiles)+#13+ 'DT: '+IntToStr(Zeit2 div 2)+' ms'+#13+ 'gefundene Dateien: '+IntToStr(FindFiles.InstanceSize)+#13+ 'FS: '+IntToStr(Zeit3 div 2)+' ms'+#13+ 'gefundene Dateien: '+IntToStr(Found)); end;
end. |
Ergebnis:
- SearchTool(v2.0.3): 4164 ms
- DriveTools(v3.0): 7437 ms
- retFileSearch (v4): 6695 ms
Zum Ergebnis muss ich allerdings ein noch sagen. Bei Luckie werden die gefundenen Pfade nicht eingespeichert (oder ich habe nix gefunden wo es gemacht wird), dadurch entfällt ja die Zugriffs- und Schreibezeit auf dem RAM. Des weiteren ließ sich bei Luckie nicht überprüfen, ob er genauso wiel Dateien gefunden hat, da wie gesagt er nirgendswo etwas zusätzlich einspeichert .
Allerdings kam die Units nicht ganz vergleichen, denn jede Unit bietet mehr oder weniger zusätzliche Schnittstellen, die die Performance evtl. verlangsamen. Aber vom reinen Suchen dürfte es auf jeden Fall zu sehen sein, welche Unit die Nase vorne hat .
|
|
Luckie
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Mo 24.10.05 12:44
Heiko hat folgendes geschrieben: | Bei Luckie werden die gefundenen Pfade nicht eingespeichert (oder ich habe nix gefunden wo es gemacht wird) |
Das wird dir doch alles per Nachricht zu geschickt.
|
|
retnyg
Beiträge: 2754
SNES, GB, GBA, CPC, A500, 486/66, P4/3.0HT: NintendOS, AmigaOS, DoS
Delphi 5, Delphi 7
|
Verfasst: Mo 24.10.05 17:07
Heiko hat folgendes geschrieben: |
Ergebnis:
- SearchTool(v2.0.3): 4164 ms
- DriveTools(v3.0): 7437 ms
- retFileSearch (v4): 6695 ms
|
deine unit ist in der tat die schnellste, nachdem die dateisuche von windows gecached wurde.
die resultate von dir sind gecachte messzeiten.
mach mal deinen speicher voll (z.b. n delphi-prog das mit getmem viel speicher alloziert), so dass der wert "zugesichter speicher" im taskmanager grösser als der wert deines physikalischen arbeitsspeicher ist.
so werden die suchen nicht gecached, und du siehst welche strategie beim reinen festplattenhandling die nase vorn hat.
bei meinen messungen waren hier alle 3 units gleichschnell (abweichungen/schwankungen bis zu 3-4%), allerdings bei unterschiedlichem funktionsumfang.
_________________ es gibt leute, die sind genetisch nicht zum programmieren geschaffen.
in der regel haben diese leute die regel...
|
|
retnyg
Beiträge: 2754
SNES, GB, GBA, CPC, A500, 486/66, P4/3.0HT: NintendOS, AmigaOS, DoS
Delphi 5, Delphi 7
|
Verfasst: Mo 24.10.05 18:55
retnyg hat folgendes geschrieben: | deine unit ist in der tat die schnellste, nachdem die dateisuche von windows gecached wurde. |
nein, das stimmt so nicht: deine unit nur die schnellste, wenn man nur nach einem dateityp sucht.
sucht man nach *.* oder *.mp3;*.m3u ist meine schneller. wenn man bei meiner unit nach *.mp3;*.mp3 sucht ist sie doppelt so schnell als nur bei *.mp3
das werde ich noch optimieren.
_________________ es gibt leute, die sind genetisch nicht zum programmieren geschaffen.
in der regel haben diese leute die regel...
|
|
Heiko
Beiträge: 3169
Erhaltene Danke: 11
|
Verfasst: Mo 24.10.05 19:18
Luckie hat folgendes geschrieben: | Heiko hat folgendes geschrieben: | Bei Luckie werden die gefundenen Pfade nicht eingespeichert (oder ich habe nix gefunden wo es gemacht wird) |
Das wird dir doch alles per Nachricht zu geschickt. |
Jupp weiß ich, des wegen findet man ja auch nix, wo etwas eingespeichert wurde . Da ich aber nicht noch was zusätzlich einbauen wollte, wo evtl. Performance verloren geht, konnte ich keine Verhgleiche ziehen, ob er wirklich alles gefuden hat .
retnyg hat folgendes geschrieben: | retnyg hat folgendes geschrieben: | deine unit ist in der tat die schnellste, nachdem die dateisuche von windows gecached wurde. |
nein, das stimmt so nicht: deine unit nur die schnellste, wenn man nur nach einem dateityp sucht.
sucht man nach *.* oder *.mp3;*.m3u ist meine schneller. wenn man bei meiner unit nach *.mp3;*.mp3 sucht ist sie doppelt so schnell als nur bei *.mp3
das werde ich noch optimieren. |
Gemerkt das du dir selber widersprochen hast? Erst machste eine Aussage, danch zitierst du dich selber und bahauptest das die Aussage falsch ist . Das er bei *.mp3;*.mp3 doppelt so lange braucht ist eine gute Idee noch zu verbessern .
@Cache: Eigentlich nutzt jede Unit von uns den Cache. Zu mindestens war es bei der DriveTools von Luckie das gleiche Symton und ich glaube nicht das er es entfernt hat, was ja Nachteilig wäre . Und ich so weit iczh gesehen habe beruhhst du auf dem gleichem Symtom. Von daher ... .
|
|
retnyg
Beiträge: 2754
SNES, GB, GBA, CPC, A500, 486/66, P4/3.0HT: NintendOS, AmigaOS, DoS
Delphi 5, Delphi 7
|
Verfasst: Mo 24.10.05 19:39
Heiko hat folgendes geschrieben: | Gemerkt das du dir selber widersprochen hast? |
nein, ich habe nur was richtiggestellt.
also: aus dem cache heraus ist deine unit die schnellste, wenn man nur nach einem dateityp sucht.
bei allen anderen aufgaben ist meine unit schneller.
deswegen die berichtigung.
Heiko hat folgendes geschrieben: | Das er bei *.mp3;*.mp3 doppelt so lange braucht ist eine gute Idee noch zu verbessern . |
nein, es ist genau umgekehrt.
Heiko hat folgendes geschrieben: | @Cache: Eigentlich nutzt jede Unit von uns den Cache. Zu mindestens war es bei der DriveTools von Luckie das gleiche Symton und ich glaube nicht das er es entfernt hat, was ja Nachteilig wäre . Und ich so weit iczh gesehen habe beruhhst du auf dem gleichem Symtom. Von daher ... . |
ja, zum cache: wenn der code im alltag hergenommen wird, läuft der code zu 90% `NICHT aus dem cache.
wenn ich nach etwas suche, dann normalerweise nur 1x, und nicht 10mal um die zeit zu messen.
deshalb ist der wert, der für die praxis interessanter ist, der ungecachte.
wenn du die performance-krone für die dateisuche willst, musst du mehr testen als nur den einen bereich, wo dein code die nase vorn hat. sonst ist das wie bei intel, die ihre benchmarks für die eigenen cpu's optimieren
_________________ es gibt leute, die sind genetisch nicht zum programmieren geschaffen.
in der regel haben diese leute die regel...
|
|
Heiko
Beiträge: 3169
Erhaltene Danke: 11
|
Verfasst: Mo 24.10.05 19:55
|
|
retnyg
Beiträge: 2754
SNES, GB, GBA, CPC, A500, 486/66, P4/3.0HT: NintendOS, AmigaOS, DoS
Delphi 5, Delphi 7
|
Verfasst: Mo 24.10.05 20:25
wenn du gerade am debuggen bist: deine aktuelle variante liefert bei *.* oder * zu wenig treffer
_________________ es gibt leute, die sind genetisch nicht zum programmieren geschaffen.
in der regel haben diese leute die regel...
|
|
Heiko
Beiträge: 3169
Erhaltene Danke: 11
|
Verfasst: Di 25.10.05 06:48
Mhm, wenn ich bei mir vergleiche wieviel Daten auf C sind und wieviel er findet stimmen die schon. Meine Unit findet 133.037 Dateien und wenn ich bei C Strg+A und dann Eigenschaftenm mache, findet er 132.921 Daten. Warum er mehr findet kann ich dir gerade nicht sagen, aber es kann kein Bug sein vom Filter, denn der würde maximal verusrachen, das zu wenige da sind. Evtl. macht er bei den Egenschaften Systemdaten nicht mit, während die Unit ein paar Typen vom System noch findet.
Aber wie kommste darauf das er zu wenig findet? Findet er bei dir etwa nicht alle (v2.0.3?)?
|
|
retnyg
Beiträge: 2754
SNES, GB, GBA, CPC, A500, 486/66, P4/3.0HT: NintendOS, AmigaOS, DoS
Delphi 5, Delphi 7
|
Verfasst: Di 25.10.05 13:56
der explorer sagt auf E: liegen 176.000 dateien.
das selbe sagt auch meine unit.
deine neueste unit sagt es wären 171.000
_________________ es gibt leute, die sind genetisch nicht zum programmieren geschaffen.
in der regel haben diese leute die regel...
|
|
Heiko
Beiträge: 3169
Erhaltene Danke: 11
|
Verfasst: Di 25.10.05 16:31
Ich habs vermutet dass du mit der Windowssuche vergleichst. Das Ergebnis stimmt jedoch nicht ganz, denn die Windowssuche sucht auch in zip-Dateien nach Dateien, während meine zip-Archive nicht durchsucht. Des wegen dieser Unterschied . Würde mich aber mal interessieren, warum deiner die findet .
|
|
retnyg
Beiträge: 2754
SNES, GB, GBA, CPC, A500, 486/66, P4/3.0HT: NintendOS, AmigaOS, DoS
Delphi 5, Delphi 7
|
Verfasst: Di 25.10.05 16:51
wer redet von suchen ? E: öffnen, STRG-A, ALT-ENTER
_________________ es gibt leute, die sind genetisch nicht zum programmieren geschaffen.
in der regel haben diese leute die regel...
|
|
mimi
Beiträge: 3458
Ubuntu, Win XP
Lazarus
|
Verfasst: So 06.11.05 11:21
So eine unit habe ich schon lange gesucht, ich habe sie jetzt zwar noch nicht getestet aber kann ich denn beim suchen die unterverzeichnise ausschalten ?
also so das nur das hauptverzeichnis durchsucht wird und nicht die andren die es evtl. noch geben könnte.
So mal schauen welche unit ich nehme, warscheinlich die von
"retnyg"
evlt. teste ich auch mal alle ich habe ein verzeichnis mit über 3000 midi dateien *G* ich fände es auserdem nicht schlecht wenn eine datei gefunden wird ein ereignis ausgelöst wird. Das hat den vorteil das ich die gefunden dateien nicht erst umwandel muss.
aber dies sollte ein und ausgeschlatet werden können.
_________________ MFG
Michael Springwald, "kann kein englisch...."
|
|
Heiko
Beiträge: 3169
Erhaltene Danke: 11
|
Verfasst: So 06.11.05 11:33
mimi hat folgendes geschrieben: | So eine unit habe ich schon lange gesucht, ich habe sie jetzt zwar noch nicht getestet aber kann ich denn beim suchen die unterverzeichnise ausschalten ? |
Ob die Unterordner mit durchsucht werden sollen oder nicht, kannst du bei allen 3 Units angeben.
mimi hat folgendes geschrieben: | evlt. teste ich auch mal alle ich habe ein verzeichnis mit über 3000 midi dateien *G* |
Bei midi dürfte mein Filter keine Probleme haben. ICh habe den Bug schon gefunden, aber bisher keine Zeit gehabt den auszubessern, da ich beim BwInf teilnehme.
mimi hat folgendes geschrieben: | ich fände es auserdem nicht schlecht wenn eine datei gefunden wird ein ereignis ausgelöst wird. Das hat den vorteil das ich die gefunden dateien nicht erst umwandel muss.
aber dies sollte ein und ausgeschlatet werden können. |
Was meinst du mit umwandeln? Und das mit dem Ereignis kann momentan Luckies Unit, wenn ich dich richtig verstanden habe, was du haben willst .
|
|
retnyg
Beiträge: 2754
SNES, GB, GBA, CPC, A500, 486/66, P4/3.0HT: NintendOS, AmigaOS, DoS
Delphi 5, Delphi 7
|
Verfasst: So 06.11.05 14:11
_________________ es gibt leute, die sind genetisch nicht zum programmieren geschaffen.
in der regel haben diese leute die regel...
|
|
mimi
Beiträge: 3458
Ubuntu, Win XP
Lazarus
|
Verfasst: So 06.11.05 15:01
@Heiko
mit umwanden meine ich z.b.: meistens wird ja eine TStringList erwartet aber wenn dies nicht der fall währe so wie bei luckie dort habe ich gelesen wird ein TStringArray erwartet.
aber wenn lucki's such funktioen ereignis unterstützt werde ich das in zukunpft verwenden. ja oder evlt. doch die von retnyg....
ich habe mir dem umfang noch nicht angeschaut nur mal die geschwindigkeits vergleiche, aber dies ist doch auch nur relativ: Das kommt doch auch drauf an wie schnell die festplatten sind und wie sie ausgelastet sind...
_________________ MFG
Michael Springwald, "kann kein englisch...."
|
|
|