Frage zu Everything wegen Datei-Details (Größe, Datum, Zeit)

German support forum

Moderators: Hacker, Stefan2, white

Post Reply
TW
Senior Member
Senior Member
Posts: 390
Joined: 2005-01-19, 13:35 UTC

Frage zu Everything wegen Datei-Details (Größe, Datum, Zeit)

Post by *TW »

Neu in RC4 ist ja
...die verbesserte Suche mit "Everything" 1.4, bei dem TC die Dateiattribute direkt von der Datenbank bezieht. Das sollte die Suche weiter beschleunigen.
Ich nehme an, jetzt muss man in Everything zusätzliche Sachen indexieren? Bei mir sieht das jetzt so aus:

http://www.imagebam.com/image/bb04a1513038106

Ist wohl der Standard, aber reicht ja jetzt wohl nicht aus für die neuen Funktionen? Oder doch? In Everything selber sind diese Angaben wie "Attribute" bei mir trotzdem da, obwohl nicht indexiert.
licenced and happy TC user since 1994 (#11xx)
User avatar
Horst.Epp
Power Member
Power Member
Posts: 6979
Joined: 2003-02-06, 17:36 UTC
Location: Germany

Post by *Horst.Epp »

Die Einstellungen reichen völlig.
Die Indexierung ist nur für die Sortierungen interessant.
TC kommt mit diesen Settings klar.
Die aktuelle Everything Beta Version ist zur Zeit übrigens:
Version 1.4.1.789b (x64)

Die Everything 1.4.1 Beta Nightly Builds gibts hier:
http://www.voidtools.com/forum/viewtopic.php?f=2&t=5718
Windows 11 Home, Version 24H2 (OS Build 26100.4061)
TC 11.55 RC2 x64 / x86
Everything 1.5.0.1391a (x64), Everything Toolbar 1.5.2.0, Listary Pro 6.3.2.88
QAP 11.6.4.4 x64
TW
Senior Member
Senior Member
Posts: 390
Joined: 2005-01-19, 13:35 UTC

Post by *TW »

Ich benutze v1.4.1.790b (x86)

Ich frage bloss, weil ich jetzt so gefühlsmässig keinen grossen Geschwindigkeitszuwachs erkenne zur RC3.

Geben ich in Everything selber bei meiner ext. Platte *.jpg ein, kommt da innert Bruchteilen einer Sekunde das Ergebnis (~386'000 Dateien).
Während der TC nach wie vor Verzeichnisse abgrast und für dieselbe Suche (eben getestet) 78 Sekunden benötigt.

Es ist also weiterhin so: Für eine Suche, wo wenige Funde zu erwarten sind, ist die "Everything Suche" extrem schnell, bei vielen Funden nimmt die Geschwindigkeit dramatisch ab. Der TC muss offenbar nach wie vor zusätzliche Informationen zu jeder Datei sammeln.

Das ist auch so, wenn ich ev: *.jpg benutze.
licenced and happy TC user since 1994 (#11xx)
TW
Senior Member
Senior Member
Posts: 390
Joined: 2005-01-19, 13:35 UTC

Post by *TW »

Sodele, ich habe mal eine kleine Testreihe gestartet.

Dieselbe Platte, ca 386'000 *.jpg Dateien

TC RC3 x86, Everything x86 - 1:50 Minuten
TC RC4 x86, Everything x86 - 1:15 Minuten

Beide mehrmals getestet, mit sehr ähnlichen Zeiten. Trotzdem ist das natürlich nichts wissenschaftliches.

Interessant auch, dass TC x64 zusammen mit Everything x64 immer ein klein wenig langsamer war.

RC4 ist also durchaus schneller, aber meilenweit vom Everything GUI (<1 Sek.) selber entfernt. Ich vermute aber mal, dass da systembedingt leider nicht mehr drin liegt.
Für Massen-Umbenennungen ist man also mit dem Everything GUI besser bedient.
licenced and happy TC user since 1994 (#11xx)
User avatar
Horst.Epp
Power Member
Power Member
Posts: 6979
Joined: 2003-02-06, 17:36 UTC
Location: Germany

Post by *Horst.Epp »

TW wrote:Sodele, ich habe mal eine kleine Testreihe gestartet.

Dieselbe Platte, ca 386'000 *.jpg Dateien

TC RC3 x86, Everything x86 - 1:50 Minuten
TC RC4 x86, Everything x86 - 1:15 Minuten

Beide mehrmals getestet, mit sehr ähnlichen Zeiten. Trotzdem ist das natürlich nichts wissenschaftliches.

Interessant auch, dass TC x64 zusammen mit Everything x64 immer ein klein wenig langsamer war.

RC4 ist also durchaus schneller, aber meilenweit vom Everything GUI (<1 Sek.) selber entfernt. Ich vermute aber mal, dass da systembedingt leider nicht mehr drin liegt.
Für Massen-Umbenennungen ist man also mit dem Everything GUI besser bedient.
Ich mache keine Umbennungen von hunderttausenden Dateien,
weder mit Everything, noch mit dem TC.
Das Everything GUI zeigt einfach Daten aus seiner Datenbank direkt an
und ist deshalb immer schneller als jeder Aufruf per API.
Im praktischen Betrieb ist TC mit Everything, speziell seit RC4, besser als alles andere auf dem Markt der Datei Manager.
Windows 11 Home, Version 24H2 (OS Build 26100.4061)
TC 11.55 RC2 x64 / x86
Everything 1.5.0.1391a (x64), Everything Toolbar 1.5.2.0, Listary Pro 6.3.2.88
QAP 11.6.4.4 x64
User avatar
milo1012
Power Member
Power Member
Posts: 1158
Joined: 2012-02-02, 19:23 UTC

Post by *milo1012 »

TW wrote:RC4 ist also durchaus schneller, aber meilenweit vom Everything GUI (<1 Sek.) selber entfernt. Ich vermute aber mal, dass da systembedingt leider nicht mehr drin liegt.
Für Massen-Umbenennungen ist man also mit dem Everything GUI besser bedient.
TC muss beim Zusammenstellen des Suchergebnis ja im Speicher eine eigene "Map" füllen, also eine Zuordnung von Schlüssel und Daten für einen "virtuellen" Datei-/Ergebnis-Baum, und das dauert eben seine Zeit, während Everything die eigenen internen Daten einfach zusammensucht und lediglich verlinkt. Deswegen kann TC schon theoretisch nie die gleiche Geschwindigkeit haben.

Allerdings ist mir jetzt mit Everything (und auch schon vorher durch einen Test auf einer schnellen SSD) aufgefallen:
Die internen Datenstrukturen die TC benutzt sind ziemlich ineffizient. Wenn ich jetzt testweise im TC 9.0 RC 4 x64 mit der Suchfunktion und aktiviertem Everything nach ~1,2 Mio Dateien (auf allen lokalen Platten) suche, braucht TC 4,5 Minuten um alles zusammenzustellen. Der Speicherverbrauch liegt bei etwa ~800 MB, was aber für die Anzahl der Dateien in Ordnung ist, die Zeit ist es aber eher nicht. Nachdem ich die Suchergebnisse angewendet habe (Feed to listbox), steigt der Speicherverbrauch auf 1,2 GB, was auch noch erklärbar ist, da das Ergebnis jetzt quasi doppelt im RAM vorliegt.
Aber:
Verwerfe ich nun das Suchergebnis, z.B. indem ich ins vorige Verzeichnis navigiere (Alt+Links) fängt TC an die interne Map zu löschen. Nur: das dauert sage und schreibe 88 Minuten! Beim Löschvorgang erzeugt TC unglaubliche 3,2 Mrd. (Milliarden!) Page Faults (zu sehen z.B. im Process Explorer). Der Speicherverbrauch steigt während des Löschens sogar zeitweilig auf ~1,95 GB an. Gerade die Page Faults sagen mir, dass es sich um eine ziemlich ineffiziente Art einer Datenstruktur handelt, vermutlich mit sehr kleinen Chunks (eine einfache verkettete Liste bzw. Linked List?).

Bei einem 32-bit-System war das aufgrund des begrenzten Adressraums und der eventuell vorhanden Fragmentierung von diesem durchaus sinnvoll, aber bei TC x64 und einem System mit weit über 2 GB RAM ist das wirklich nicht mehr zeitgemäß. Wäre vielleicht Zeit, in eine Datenstruktur zu wechseln, die den Gegebenheiten eines x64-Systems angemessen ist und bei der das Löschen nicht eine Größenordnung länger braucht als das Erstellen und sogar noch mehr RAM veranschlagt.
TC plugins: PCREsearch and RegXtract
TW
Senior Member
Senior Member
Posts: 390
Joined: 2005-01-19, 13:35 UTC

Post by *TW »

Ich mache keine Umbennungen von hunderttausenden Dateien,
Nun, ich eben schon. Nicht gerade hunderttausende, aber doch sehr viele. Habe natürlich absichtlich ein extremes Beispiel genommen.

Da das MRT von Everything auch sehr gelungen ist, werde ich für solche Situationen weiterhin dieses verwenden.

TC muss beim Zusammenstellen des Suchergebnis ja im Speicher eine eigene "Map" füllen, also eine Zuordnung von Schlüssel und Daten für einen "virtuellen" Datei-/Ergebnis-Baum, und das dauert eben seine Zeit, während Everything die eigenen internen Daten einfach zusammensucht und lediglich verlinkt. Deswegen kann TC schon theoretisch nie die gleiche Geschwindigkeit haben.
Das meinte ich ja eigentlich auch mit "systembedingt".
licenced and happy TC user since 1994 (#11xx)
User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 50550
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) »

TC ist nicht für 100'000e Dateien ausgelegt. Die Dateiliste wird in Objekten gespeichert, eines pro Datei. Everything speichert dagegen alles in einem durchgehenden Speicherbereich. Das ist OK, solange keine Manipulationen in der Liste nötig sind, würde aber im TC nicht funktionieren.

Ausserdem wird nach der Everything-Suche das Suchergebnis noch durch die TC-eigene Suchfunktion geleitet, um erweiterte Operation wie Suche nach Grösse, Datum, Attributen, Plugins oder Inhalt durchzuführen.
Author of Total Commander
https://www.ghisler.com
User avatar
milo1012
Power Member
Power Member
Posts: 1158
Joined: 2012-02-02, 19:23 UTC

Post by *milo1012 »

ghisler(Author) wrote:Die Dateiliste wird in Objekten gespeichert, eines pro Datei.
Was ja auch so sein soll, nur sollte beim Löschen von Objekten nicht derartig viel CPU-Zeit (Kernel-Zeit!) in Anspruch genommen werden. Es scheint, als ob beim Löschen von jedem zweiten (oder jedem?) Objekt der halbe Heap umstrukturiert wird. Kein Wunder dass es dann unzählige Page Faults (Seitenfehler) gibt. Ich bin nicht sicher wie es bei Delphi aussieht und wie es TC überhaupt handhabt, aber es ist ja allgemein bekannt dass bei z.B. C++ STL-Containern das Objektmanagement mit einem eigenen privaten Heap erfolgt, der den Speicher nur in jeweils größeren Blöcken alloziert und wieder freigibt und ansonsten nur Füllstandmelder und Pointer bearbeitet, so dass je nach Objektgröße bei vielleicht nur jedem hundertsten oder tausendsten Löschvorgang ein API-Aufruf zwecks Speichermangement geschehen muss. Ich kann dort in selbstgeschriebenen Programmen einen Container mit 1 Mio. Objekten anlegen, einzelne oder alle Objekte beliebig manipulieren und löschen, und das Ganze in unter einer Minute. Mag aber sein, dass es bei einer echten Dateiliste mit Attributen etwas anders aussieht.

Das sollte auch keine allgemeine Kritik sein, nur ist es gerade jetzt mit TC 9 und Everything und/oder SSDs einfacher denn je, sehr schnell sehr große Ergebnislisten zu erzeugen, und so fällt es eben manchmal schon unangenehm auf. Es würde mich nicht wundern, wenn es in naher Zukunft mehr von solchen Meldungen à la "TC reagiert nicht wenn ich das Suchergebnis verwerfe" gibt. Und falls sich noch jemand an User makinero aus dem englischen Forum erinnert, er hatte Ähnliches versucht, allerdings mit 10 Mio Dateien (kann ich nicht mehr nachprüfen, da er seine eigenen Posts gelöscht hat).

Suchergebnisse jenseits von 1 Mio Einträgen sind natürlich praxisfremd, aber als ein etwas praxisnäheres Beispiel:
Ich habe etwa 240.000 Bilddateien auf den lokalen Platten, nach denen ich Suche.
Zeit um Ergebnisse zusammenzustellen: 25 Sekunden
Speicherverbrauch: ~165 MB
Speicherverbrauch nach anwenden der Ergebnisse: ~180 MB
Zeit zum Löschen: 2 Minuten und 40 Sekunden
Spitzen-Speicherverbrauch beim Löschen: ~375 MB
110 Mio. Page Faults

Auch hier fällt die Zeit zum Leeren des Speichers unangenehm auf, und der Speicherverbrauch hat sich beim Löschen nahezu verdoppelt.
TC plugins: PCREsearch and RegXtract
User avatar
HolgerK
Power Member
Power Member
Posts: 5411
Joined: 2006-01-26, 22:15 UTC
Location: Europe, Aachen

Post by *HolgerK »

<OffTopic>
milo1012 wrote: Und falls sich noch jemand an User makinero aus dem englischen Forum erinnert, er hatte Ähnliches versucht, allerdings mit 10 Mio Dateien (kann ich nicht mehr nachprüfen, da er seine eigenen Posts gelöscht hat).
Es waren 320 Millionen Einträge:
makinero: Total Commander - can not open 320 mln files(subfolders) wrote:Total Commander - can not open subfolders 320 mlnof files (63 bytes). Application 100% freezes. ...
...
I mean this: Commands -> search -> Small files without extension -> 320 mln -> Feed to listbox (not work)..
Aber für diesen speziellen User wurden wahrscheinlich Lebensweisheiten wie "A fool with a tool is still a fool" oder "Wenn das einzige Werkzeug ein Hammer ist, sieht jedes Problem wie ein Nagel aus" extra formuliert.
(kann ich nicht mehr nachprüfen, da er seine eigenen Posts gelöscht hat).
Das kann er nicht ohne Hilfe eines Moderators oder Administrators gemacht haben.
Normalerweise kann nur das Eingangsposting dauerhaft vom Ersteller bearbeitet werden und Postings innerhalb eines Threads dürfen nur 8 Tage lang bearbeitet werden:
-> Modifications made to forum software
Das in diesem Fall, ca. 100 Threads mit insgesamt mehr als 800 Postings (nicht nur seinen eigenen :shock:) verschwinden, ist schon sehr ungewöhnlich.
</OffTopic>

Gruss
Holger
Post Reply