Inhaltsplugin: DirSize bei großen Verzeichnissen

[Lefteous]

2DrTob
Finde ich gut, dass du das Thema noch mal aufgreifst. Ich bin bei allen Verbesserungen dabei, die einen Abbruch der Sortierung beinhalten.

[Shiweia]

Ich habe diese Problematik während der Entwicklung der Inhaltsplugin-Schnittstelle mit Ghisler diskutiert, hatte aber auch keinen wirklich guten Vorschlag, wie man das besser machen könnte.

[Lefteous]

2Shiweia
Ja, ich kann mich auch erinnern, dass das erörtert wurde. An inhaltliche Details kann ich mich aber kaum noch erinnern. Ist wohl zu lange her.

Man könnte es so formulieren: Warum sollten sich die Sortierung mit Inhaltsplugin-Feldern anders verhalten als mit dem internen Größenfeld? Dort drückt man ESC und die Berechnung und damit auch die Sortierung wird gestoppt.

[HolgerK]

2Lefteous

Du unterhältst dich mit einer Maschine!

Ich glaube kaum das Shiweia ernsthaft den Turing-Test besteht indem er dich aus dem Jahr 2007 zitiert und ansonsten nur belanglose Postinhalte von sich gibt.

Gruss
Holger

[Lefteous]

2HolgerK
Ach du scheisse! Ich habe selbst hier im Forum vor diesen Maschinen gewarnt und falle jetzt selbst drauf rein

P.S.: Aber okay, vielleicht lesen außer der Maschine auch noch andere mit?

[milo1012]

Unabhängig von der (vermeintlichen) Bot-Problematik:
Ich wäre auch an einer Verbesserung interessiert.

Meine Inhaltsplugins brauchen u.U. auch ewig bis Ergebnisse da sind, aber abbrechen ist bei Sortierung einfach nicht möglich.

Ich glaube es würde ein Update des Wdx-Interface helfen, indem z.B. ContentGetValueEx eingeführt wird,
was generell in einem Hintergrundthread ausgeführt wird, ähnlich wie es mit ft_delayed bisher gemacht wird.
Über ContentSendStateInformation würden dann Anfragen zusätzlich abbrechbar sein, wenn es an einer langen Einzelanfrage hängt, wie bisher auch.

Ist dann abgebrochen wird eben auf eine Standardsortierung gesprungen, oder auf die letzte (unsortierte) Ansicht, sofern vorhanden.

Man könnte ft_delayed ja auch bei der Sortierung nutzen, aber ich denke nur wenige plug-ins nutzen es,
weswegen eine neue Funktion das Ganze forcieren würde.

Klar, man müsste einige Plug-ins anpassen und Thread-sicher machen, aber das wäre ja weniger das Problem.
Bei der Gelegenheit könnte man auch eine Plug-in-Konfiguration für wdx einbauen (aber das ist wohl Wunschdenken).

[Lefteous]

2milo1012
Es gibt ja bereits die Funktion ContentStopGetValue. Diese wird von DirSizeCalc auch implementiert. Das Problem ist, dass die Sortierung im Vordergrund einfach wartet, bis alle Daten da sind. ContentStopGetValue wird derzeit meines Wissens nach in diesem Zusammenhang nicht aufgerufen, nur bei Verzeichniswechseln etc.

[milo1012]

Das Problem ist, dass die Sortierung im Vordergrund einfach wartet, bis alle Daten da sind. ContentStopGetValue wird derzeit meines Wissens nach in diesem Zusammenhang nicht aufgerufen, nur bei Verzeichniswechseln etc.

Richtig.
und ContentStopGetValue ist genau wie ContentSendStateInformation optional.
Aber TC benutzt trotz dieser exportierten Funktionen nichts dergleichen beim Sortieren.

Vernünftiges Abbrechen geht meines Erachtens nach nur mit HG-Threads.
TC weiß aber nicht vorher ob ft_delayed kommt, oder ob ContentStopGetValue immer funktioniert,
da beim Laden keine Abfrage nach Plug-in-Features stattfindet, weswegen eine neue Funktion m.M. nach sinnvoll wäre.

Dann einfach schauen ob die aktuelle Sortierung aus einem Plug-In mit neuer Funktion kommt,
und alles mit typischen "bitte warten..." Dialog versehen.

[Lefteous]

2milo1012
Die Sortierfunktion geht ja im Grunde auch nur hin und liest einen Wert nach dem anderen, dann sortiert sie. Ich denke man kann erwarten, dass währenddessen auf Tastatureingaben überprüft wird. Drückt der Nutzer nun also ESC, sollte folgendes passieren:
1) Worst case. Es wird gerade ein Wert im Vordergrund gelesen. Es wird also gewartet, bis dieser _eine_ Wert gelesen wird und dann wird die Queue gelöscht und nur für die bisher gelesenen Werte sortiert.
2) Es wird gerade ein Wert im Hintergrund gelesen. TC sendet ContentStopGetValue an das Plugin, das daraufhin schnellstmöglich die aktuelle Berechnung abbricht. Der Rest der Queue wird auch hier gelöscht und nur für berechnete Werte sortiert.

Das ist so nahestmöglich an dem Verhalten von Alt+Shift-Enter bei entsprechender Sortierung. Ich denke das wäre doch erst mal okay.

Aus meiner Sicht gibt es also keinen Grund/Mehrwert vorher zu wissen, ob Hintergrundverarbeitung unterstützt bzw. tatsächlich durchgeführt wird. Am Ende muss man den Worst Case ohnehin mit abdecken.

[milo1012]

Am Ende muss man den Worst Case ohnehin mit abdecken.

Natürlich, deswegen wäre die Funktion ja auch optional.

Aus meiner Sicht gibt es also keinen Grund/Mehrwert vorher zu wissen, ob Hintergrundverarbeitung unterstützt bzw. tatsächlich durchgeführt wird.

Nochmal: Es ist schon ein Unterschied ob TC vorher weiß dass ein wdx-Plug-in bei jedem Aufruf Thread-sicher ist oder nicht.
Das Ganze nur auf Anfrage (das Plug-in entscheidet selbst ob es ft_delayed rückgibt) ist IMO eine Design-Schwäche.
Und dass ein Vordergrund-Thread nicht mehr wirklich auf UI-Anfragen reagieren kann ist ja allgemein bekannt, weswegen solche Sachen bei z.b. Android überhaupt nicht kompilieren würden.
Eine blockierte UI möchte ich im Jahr 2015 und mit Multi-Core-CPUs eigentlich nicht mehr sehen.

ft_delayed wird sowohl in der normalen Suche (Alt+F7) als auch beim Sortieren konsequent ignoriert, wie ich selbst feststellen musste.
Und in der normalen Benutzerdefinierten Spaltenansicht funktioniert es auch erst seit 8.50 richtig, weil es vorher verbuggt war.

Wenn es also möglich wäre, wieso hat Christian es dann nicht eingebaut?

Dieser Thread hier hat bis 2007 geruht, also knapp 8 Jahre hat sich nicht wirklich was getan.
So wie ich das sehe wurde WDX mit der Ansicht entwickelt: "die Felder sind in 99% der Fälle in < 1s da".
Dem ist aber nicht immer so.
Würde also nicht schaden das Wdx-Interface mal zu aktualisieren.
Die Anforderungen sind einfach nicht mehr die selben wie damals, wie sich jetzt nach und nach zeigt.




Nachtrag:
Ich danke dir für den Vorschlag an dieser Stelle
Wollte schon öfters mal selbst einen Thread diesbezüglich verfassen.

[Lefteous]

2milo1012

Es ist schon ein Unterschied ob TC vorher weiß dass ein wdx-Plug-in bei jedem Aufruf Thread-sicher ist oder nicht.

Das kann er in keinem Fall wissen. When ft_delayed zurückgegeben wird, dann erwartet der TC natürlich Threadsicherheit. Das ist aber - wie andere Mechanismen auch - eine Konvention.

Das Ganze nur auf Anfrage (das Plug-in entscheidet selbst ob es ft_delayed rückgibt) ist IMO eine Design-Schwäche.

Wenn überhaupt dann ist das ein Performanceproblem. Das könnte man sicher eleganter machen, indem man es über den Typ abbildet und dann nicht erst im Vordergrund aufruft. Da wäre ich dabei.

ft_delayed wird sowohl in der normalen Suche (Alt+F7) als auch beim Sortieren konsequent ignoriert, wie ich selbst feststellen musste.

Das läuft ja immer konsequent im Vordergrund. Allerdings auf Wunsch in einem Extra-Prozess. Da sehe ich die Notwendigkeit nicht.

Wenn es also möglich wäre, wieso hat Christian es dann nicht eingebaut?

Die Mechanismen sind vielleicht nicht perfekt, aber reichen eigentlich aus. Man muss es als Pluginentwickler nur nutzen und TC müsste es nur umfassender aufrufen.

So wie ich das sehe wurde WDX mit der Ansicht entwickelt: "die Felder sind in 99% der Fälle in < 1s da".
Dem ist aber nicht immer so.

Also DirSizeCalc unterstützt Multi-Threading seit 2004/2005 - von daher kann ich deine Aussage gar nicht nachvollziehen.

Und dass ein Vordergrund-Thread nicht mehr wirklich auf UI-Anfragen reagieren kann ist ja allgemein bekannt

Sicher, nur wenn man eben nur das hat, dann muss man das beste draus machen. Kommt der Interrupt geflogen, dann kann man da schon was machen. Ich will natürlich den Worst Case nicht zum Ideal hochstilisieren, aber es kommt sicher häufig vor.


Wie dem auch sei. Natürlich wären ein paar API-Verbesserungen wünschenswert. Aber auch ohne könnte man das Sortierproblem erheblich entschärfen.

[milo1012]

Das kann er in keinem Fall wissen. When ft_delayed zurückgegeben wird, dann erwartet der TC natürlich Threadsicherheit. Das ist aber - wie andere Mechanismen auch - eine Konvention.

Es ging um die von mir angesprochene neue Funktion, welche immer Thread-sicher sein soll.
Mal abgesehen davon: bei WCX gibt es GetBackgroundFlags(), in dem man explizit melden muss was sicher ist.
Warum sollte das nicht auch für WDX übertragbar sein?

Also DirSizeCalc unterstützt Multi-Threading seit 2004/2005 - von daher kann ich deine Aussage gar nicht nachvollziehen.

DSC ist sicher eine Ausnahme, ähnlich wie mein PCREsearch, aber ich meine mich zu erinnern mindestens ein Statement von Cristian gelesen zu haben,
in dem er diese Aussage so traf, nach dem Motto "Mp3-Tags und andere Metadaten sind normalerweise schnell verfügbar".

Das läuft ja immer konsequent im Vordergrund. Allerdings auf Wunsch in einem Extra-Prozess. Da sehe ich die Notwendigkeit nicht.

Es wäre wohl kein Problem die ft_delayed-Felder auch hier in eine Warteschlange zu schieben.
Das würde das Problem schonmal etwas abschwächen.
Tut aber auch nichts zur Sache, ContentStopGetValue wird ja ignoriert.

Die Mechanismen sind vielleicht nicht perfekt, aber reichen völlig aus.

Das nehme ich jetzt mal als Meinung hin.
Ich habe auch diverse Erfahrung mit andren Software-Addons,
und wenn es Probleme gibt ist das erste was unsere Entwickler sagen: "die API schränkt zu sehr ein".
WDX ist sicher nicht "undurchdacht", aber für ein generelles Suchplugin im Dateiinhalt ist es z.B. nur eingeschränkt geeignet.
Ich habe auch eine Größenlimit in PCREsearch eingebaut, schlicht um zu verhindern dass eine 20GiB Videodatei von
PCRE minutenlang durchforstet wird, ohne dass die UI in irgendeiner Weise reagieren kann.

Sicher, nur wenn man eben nur das hat, dann muss man das beste draus machen. Kommt der Interrupt geflogen, dann kann man da schon was machen.

Interrupts? Meiner Erfahrung nach ist bei Windows GDI einfach viel zu träge um Dinge mit engen Timern zu erledigen.
Das ist ja auch der Grund dieses Threads: Würde es angenehm funktionieren hätten wir die Diskussion nicht.

[Lefteous]

2milo1012

Es ging um die von mir angesprochene neue Funktion, welche immer Thread-sicher sein soll.
Mal abgesehen davon: bei WCX gibt es GetBackgroundFlags(), in dem man explizit melden muss was sicher ist.
Warum sollte das nicht auch für WDX übertragbar sein?

Ich denke eine Flags-Funktion wäre schon die beste Lösung.

DSC ist sicher eine Ausnahme

Eine Ausnahme, die schon zur Veröffentlichung der Schnittstelle exisitiert, belegt doch, dass deine Vermutungen zur Entwicklung nicht stimmen. Was willst du denn noch für Details?

Es wäre wohl kein Problem die ft_delayed-Felder auch hier in eine Warteschlange zu schieben.
Das würde das Problem schonmal etwas abschwächen.
Tut aber auch nichts zur Sache, ContentStopGetValue wird ja ignoriert.

Man kann die Suche schon abbrechen. Klar mit einem Hintergrund-Thread und ContentStopGetValue ginge es schneller. Man darf aber natürlich nicht vergessen, dass das schon ein Spezialfall ist und der Normalfall ist, dass es im Vordergrund laufen muss, weil die meisten Sachen nicht threadafe sind.
Klar ein bisschen Optimierung schadet nie und vielleicht läuft dann eines Tages jedes Plugin im Hintergrund - auch die Packer-Plugins. Man kann doch aber jetzt nicht wirklich behaupten, dass viele Packer-Plugin-Entwickler hier bisher Wunder vollbracht haben, seitdem das geht. Und wie viele Jahre geht das jetzt schon?

WDX ist sicher nicht "undurchdacht", aber für ein generelles Suchplugin im Dateiinhalt ist es z.B. nur eingeschränkt geeignet.
Ich habe auch eine Größenlimit in PCREsearch eingebaut, schlicht um zu verhindern dass eine 20GiB Videodatei von
PCRE minutenlang durchforstet wird, ohne dass die UI in irgendeiner Weise reagieren kann.

Du hast es ja oben im Grunde selbst schon geschrieben: Es liegt größtenteils nicht an der API, sondern daran, dass der TC sie nicht überall einsetzt, wo es sinnvoll wäre.
In DirSizeCalc gibt es auch eine Limit-Option, für die gleiche Problematik.

Interrupts? Meiner Erfahrung nach ist bei Windows GDI einfach viel zu träge um Dinge mit engen Timern zu erledigen.
Das ist ja auch der Grund dieses Threads: Würde es angenehm funktionieren hätten wir die Diskussion nicht.

Der Event-Handler, den der TC einsetzt, funktioniert doch eigentlich ganz gut. Natürlich ist eine richtige Multi-Threading-Lösung schöner, aber das ist aus den oben genannten Gründen eher unrealistisch.

[milo1012]

Eine Ausnahme, die schon zur Veröffentlichung der Schnittstelle exisitiert, belegt doch, dass deine Vermutungen zur Entwicklung nicht stimmen. Was willst du denn noch für Details?

Wollen wir uns jetzt an dieser Aussage aufhängen?
Es habe einfach meinen Eindruck wiedergegeben als ich mich in die WDX-Spezifikation eingelesen habe
und ein paar Bugreports zum Thema konsultierte.
Gerade Dinge wie die Queue im Hintergrund sind IMO auch nicht vernünftig dokumentiert, und war wie schon erwähnt lange Zeit verbuggt.

Außerdem ist es Tatsache dass 90 Prozent aller WDX-Plug-ins eben nur ein paar Metadaten lesen oder den Header dekodieren,
was im Normalfall eben nicht lange dauert.
Ich glaube kaum dass Christian es damals im Sinn hatte jede Datei, incl. derer jenseits von ein paar MB, über WDX roh lesen zu lassen.
Wenn ich die Aussage von Christian finde werde ich sie posten.

Es hängt ja außerdem ein bisher noch nicht erwähntes Problemen dran.
Versuch solche Felder, die eine Minute und mehr brauchen, zu nutzen in:
-benutzerdef. Hilfstexten/Tooltips
-Überschreiben-Dialog
-MRT
...
Alles quasi unbenutzbar und nicht abbrechbar.

Wie schon erwähnt:
Entweder TC nutzt die Flags und Funktionen an dieser Stelle ebenfalls,
oder es werden neue Mechanismen für HG-Threads eingebaut. Ansonsten drehen wir uns hier im Kreis.


Es wäre schön wenn Christian sich zu dem Thema äußern könnte,
aber vermutlich ist es für TC 9 schon zu spät.