ExAll()? - amiga-news.de Forum

amiga-news.de Forum > Programmierung > ExAll()?

[ - Suche - Neue Beiträge - Registrieren - Login - ]

-1-

[ - Beitrag schreiben - ]

08.02.2010, 19:36 Uhr

MaikG
Posts: 5172
Nutzer

Kurze frage, gibt ExAll wirklich alles zurück oder nur
den Inhalt eines Verzeichnisses exclusive den Inhalt evtl.
Verzeichnisse in diesem Verzeichniss?
Den Inhalt der Unterverzeichnisse bekomme ich nicht und wollte wissen ob ich evtl. was falsch mache.
Wenn ExAll doch relativ beschränkt ist, gibt es einen merklichen
Geschwindigkeitsvorteil gegenüber ExNext()?

[ - Antworten - Zitieren - Direktlink - ]

08.02.2010, 22:04 Uhr

JoTo
Posts: 20
Nutzer

@MaikG:

So wie ich es noch drauf habe, ist ExNext ja die Urform. (Gibt es seit Kick 1.2)

Die musst du selbst so lange aufrufen bis nichts mehr gefunden wurde !
Rückgabe = immer nur ein FIB (File InfoBlock)
ExAll sucht alles auf einen Rutsch durch und ist damit auch schneller ! (Gab es erst ab Kick 2.0) Füllt einen Buffer mit allen FileInfoBlöcken

Ganz neu ist ExamineDir (ab 4.xx)
--
was here, with SamFlex on AmigaOS4.1.1

[ - Antworten - Zitieren - Direktlink - ]

09.02.2010, 08:15 Uhr

tboeckel
Posts: 124
Nutzer

Zitat:
Kurze frage, gibt ExAll wirklich alles zurück oder nur
den Inhalt eines Verzeichnisses exclusive den Inhalt evtl.
Verzeichnisse in diesem Verzeichniss?
Den Inhalt der Unterverzeichnisse bekomme ich nicht und wollte wissen ob ich evtl. was falsch mache.

Du machst was falsch! Es kann dir nur leider niemand sagen was, weil du absolut keine Infos über dein Vorgehen gegeben hast.

ExAll() arbeitet genau so wie Examine()/ExNext() natürlich nicht rekursiv und liefert dir den gesamten Inhalt eines Verzeichnisses mit möglichst wenig Aufrufen von ExAll(). Wenn du eventuelle Unterverzeichnisse mit berücksichtigen möchtest, dann mußt du das selbst tun, egal ob du ExAll() oder ExNext() verwendest.

Zitat:
Wenn ExAll doch relativ beschränkt ist, gibt es einen merklichen
Geschwindigkeitsvorteil gegenüber ExNext()?

Das hängt vom verwendeten Filesystem ab. Die müssen nämlich ExAll() unterstützen, um die Vorteile ausnutzen zu können:

code:

Note that Dos will emulate ExAll() using Examine() and ExNext()
if the handler in question doesn't support the ExAll() packet.

Das sollte klar machen, daß ExAll() nicht langsamer als ExNext() sein kann. Hätte man aber auch durch aufmerksames Lesen der Autodocs selbst herausfinden können...

[ - Antworten - Zitieren - Direktlink - ]

09.02.2010, 10:41 Uhr

MaikG
Posts: 5172
Nutzer

Zitat:
Original von tboeckel:
Du machst was falsch! Es kann dir nur leider niemand sagen was, weil du absolut keine Infos über dein Vorgehen gegeben hast.

ExAll() arbeitet genau so wie Examine()/ExNext() natürlich nicht rekursiv und liefert dir den gesamten Inhalt eines Verzeichnisses mit möglichst wenig Aufrufen von ExAll(). Wenn du eventuelle Unterverzeichnisse mit berücksichtigen möchtest, dann mußt du das selbst tun, egal ob du ExAll() oder ExNext() verwendest.

Wenn es nicht rekursiv Arbeitet mache ich doch nichts falsch.

Zitat:
Das hängt vom verwendeten Filesystem ab. Die müssen nämlich ExAll() unterstützen, um die Vorteile ausnutzen zu können:

Das sollte klar machen, daß ExAll() nicht langsamer als ExNext() sein kann. Hätte man aber auch durch aufmerksames Lesen der Autodocs selbst herausfinden können...

Das ist klar, FFS kann es, SFS wohl auch. PFS hat kaum einer und FAT95 wird es eher nicht können. Solang es emuliert wird ist Alles im grünen Bereich.
Ist nicht so berauschend der Geschwindigeitszuwachs, da man das rekusive
selbst erledigen muss.
Gibt es einen Grund warum ExAll bei manchen Programmen abschaltbar ist?
Ab OS3 sollte es doch keine Probleme machen oder?

[ - Antworten - Zitieren - Direktlink - ]

09.02.2010, 11:08 Uhr

Thore
Posts: 2266
Nutzer

> Ist nicht so berauschend der Geschwindigeitszuwachs, da man das rekusive selbst erledigen muss.

Dann machst Du da auch was falsch oder umständlich.
Denn auch wenn die Routine das selbst erledigen würde, sollte es nicht unbedingt langsamer sein als Dein eigener Code.
Wir könnten Dir besser helfen wenn wir Deinen Algorithmus kennen würden =)

[ - Antworten - Zitieren - Direktlink - ]

09.02.2010, 11:51 Uhr

tboeckel
Posts: 124
Nutzer

Zitat:
Wenn es nicht rekursiv Arbeitet mache ich doch nichts falsch.

Doch. Du hast angenommen, daß ExAll() von sich aus bereits rekursiv arbeiten könnte, obwohl nichts in der Art in irgendeiner Form dokumentiert ist. Würde es das nämlich grundsätzlich tun, dann wäre der Stackbedarf eines Programms nicht mehr kontrollierbar. Und wenn du dir die von ExAll() bereitgestellten Daten mal genau angesehen hättest, dann wäre dir auch aufgefallen, daß man bei einer rekursiven Arbeitsweise überhaupt nicht feststellen kann in welchem Verzeichnis eine Datei liegt. Alle Daten beziehen sich immer nur auf das durch "lock" angegebene Verzeichnis.

Und jetzt stell dir vor ExAll() würde wirklich grundsätzlich rekursiv arbeiten und öffne mal in Gedanken einen Filerequester auf einer Partition mit mehreren zehntausend Verzeichnissen und Dateien, die beim Öffnen des Requesters durchsucht werden...

Zitat:
Ist nicht so berauschend der Geschwindigeitszuwachs, da man das rekusive selbst erledigen muss.

Wie kommst du darauf, daß Rekursion langsam ist? Nur weil du selbst dein Hirn anstrengen mußt? Oder aus Prinzip?

Alle Einträge eines beliebig tief verschachtelten Verzeichnisbaums kann man bestimmt auch iterativ ermitteln. Aber rekursiv geht das deutlich einfacher und bestimmt nicht langsamer.

Außerdem hast du bei einer eigenen Implementierung die Kontrolle darüber, ob du Tiefensuche oder Breitensuche bevorzugst, je nach dem was für den jeweiligen Einsatz zweckmäßiger ist.

[ - Antworten - Zitieren - Direktlink - ]

09.02.2010, 14:42 Uhr

MaikG
Posts: 5172
Nutzer

Zitat:
Doch. Du hast angenommen, daß ExAll() von sich aus bereits rekursiv arbeiten könnte, obwohl nichts in der Art in irgendeiner Form dokumentiert ist.

Da machst du was falsch bezieht sich auf code und du
hast etwas falsch angenommen bezieht sich auf Dokumentation.
Aber wenn man so rechthaberisch ist, kann man im Nachhinein
auch alles auslegen wie man will

>Examines an entire directory.

Klingt für mich wie das gesamte Verzeichniss.
Also alles was dort drin ist, dazu zählen für mich nunmal
auch Unterverzeichnisse und die Dateien die darin sind.

>Würde es das nämlich grundsätzlich tun, dann wäre der Stackbedarf >eines Programms nicht mehr kontrollierbar.

Wenn es so recursiv arbeitet braucht es ziemlich genauso viel
Stack alswenn es eine Function aufruft welche recursiv arbeitet.

>Und wenn du dir die von ExAll() bereitgestellten Daten mal genau >angesehen hättest, dann wäre dir auch aufgefallen, daß man bei einer >rekursiven Arbeitsweise überhaupt nicht feststellen kann in welchem >Verzeichnis eine Datei liegt. Alle Daten beziehen sich immer nur auf >das durch "lock" angegebene Verzeichnis.

Stimmt, aber zum bestimmen der Größe wäre die lage der Daten
z.B. nicht erforderlich.

>Und jetzt stell dir vor ExAll() würde wirklich grundsätzlich >rekursiv arbeiten und öffne mal in Gedanken einen Filerequester auf >einer Partition mit mehreren zehntausend Verzeichnissen und Dateien, >die beim Öffnen des Requesters durchsucht werden...

Das ist schon klar.

>Wie kommst du darauf, daß Rekursion langsam ist?

Es geht um die Geschwindigkeitssteigerung gegenber ExNext und
die ist ebend nicht berauschend.

[ - Antworten - Zitieren - Direktlink - ]

09.02.2010, 14:56 Uhr

thomas
Posts: 7716
Nutzer

@MaikG:

Zitat:
Klingt für mich wie das gesamte Verzeichniss.
Also alles was dort drin ist, dazu zählen für mich nunmal
auch Unterverzeichnisse und die Dateien die darin sind.

Du solltest langsam anfangen, wie ein Programmierer zu denken und nicht wie ein Benutzer.

Zitat:
Es geht um die Geschwindigkeitssteigerung gegenber ExNext und
die ist ebend nicht berauschend.

Wie sollte sie ? FFS speichert die Verzeichniseinträge wild über die Partition verstreut. Da macht es keinen Unterschied, ob man einen nach dem anderen oder alle auf einmal liest, das Dateisystem muß sie so oder so einzeln durchgehen.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

09.02.2010, 15:23 Uhr

tboeckel
Posts: 124
Nutzer

Zitat:
Stimmt, aber zum bestimmen der Größe wäre die lage der Daten
z.B. nicht erforderlich.

Das sind endlich mal die Informationen, die ganz zu Anfang hätten kommen müssen.

Zitat:
Zitat:
Und jetzt stell dir vor ExAll() würde wirklich grundsätzlich rekursiv arbeiten und öffne mal in Gedanken einen Filerequester auf einer Partition mit mehreren zehntausend Verzeichnissen und Dateien, die beim Öffnen des Requesters durchsucht werden...

Das ist schon klar.

Wenn dir das alles so klar ist, warum tust du dann so als ob du es nicht wüßtest?

Zitat:
Zitat:
Zitat:
Ist nicht so berauschend der Geschwindigeitszuwachs, da man das rekusive selbst erledigen muss.
Wie kommst du darauf, daß Rekursion langsam ist?

Es geht um die Geschwindigkeitssteigerung gegenber ExNext und
die ist ebend nicht berauschend.

Lies dir bitte noch mal deinen ursprünglichen Beitrag durch. Da hast du beklagt, daß durch die nötige selbstprogrammierte Rekursion der mögliche Geschwindigkeitsgewinn wieder verloren geht. Und das ist definitiv falsch. Wenn du es anders gemeint hast, dann schreib es auch anders. So kann man dich leider nur mißverstehen!

[ - Antworten - Zitieren - Direktlink - ]

09.02.2010, 18:14 Uhr

MaikG
Posts: 5172
Nutzer

Zitat:
Original von thomas:
Wie sollte sie ? FFS speichert die Verzeichniseinträge wild über die Partition verstreut. Da macht es keinen Unterschied, ob man einen nach dem anderen oder alle auf einmal liest, das Dateisystem muß sie so oder so einzeln durchgehen.

Einen Unterschied macht es schon, im einstelligen Prozentbereich, nur keinen Großen.
Würde gleich alles komplett gelesen wäre mehr drin.

[ - Antworten - Zitieren - Direktlink - ]

09.02.2010, 19:13 Uhr

Thore
Posts: 2266
Nutzer

> Einen Unterschied macht es schon, im einstelligen Prozentbereich, nur keinen Großen. Würde gleich alles komplett gelesen wäre mehr drin.

Das ist abhängig vom Filesystem, der Fragmentierung der Platte und der Blockgröße. Der Code (ExNext oder Exall) spielt dann eine geringe Rolle prozentual gesehen.

Auch diese Routinen machen intern alles "von Hand". Eine eigene Rekursion einzubauen sollte keinen Geschwindigkeitseinbruch geben, außer man benutzt einen dämlichen Compiler und/oder einen ungeschickten Algorithmus. Wobei das Aufsammeln der Daten wohl zum Standard-Repertoir eines Programmierers gehören soll/muss.

[ - Antworten - Zitieren - Direktlink - ]

10.02.2010, 11:56 Uhr

MaikG
Posts: 5172
Nutzer

Zitat:
Original von Thore:
Das ist abhängig vom Filesystem, der Fragmentierung der Platte und der Blockgröße. Der Code (ExNext oder Exall) spielt dann eine geringe Rolle prozentual gesehen.

Wenn du einen großen Rectfill in 50 Teile teilst und 50 Aufrufe
machst ist es auch langsamer als ein einziger Rectfill Aufruf.
Die Rekursion hab ich längst drin, wie gesagt beschleunigung
im einstelligen Prozentbereich.

[ - Antworten - Zitieren - Direktlink - ]

16.02.2010, 19:44 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von MaikG:
Wenn du einen großen Rectfill in 50 Teile teilst und 50 Aufrufe
machst ist es auch langsamer als ein einziger Rectfill Aufruf.

Ja klar, es gab schon einen Grund, warum die ExAll Funktion hinzugefügt wurde. Sie hat auch den Vorteil, dass der Aufrufer angeben kann, an welchen Informationen er tatsächlich interessiert ist.

Allerdings ist eine Festplatte um Welten langsamer als der Blitter. Deshalb spielt der Overhead der Funktionsaufrufe bei ExAll eine wesentlich geringere Rolle als bei RectFill.

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

16.02.2010, 21:58 Uhr

Thore
Posts: 2266
Nutzer

Dein RectFill arbeitet im RAM, meist auf einer Interleaved Bitmap (ohne Fragmentierung) und ist schon allein daher schnell. Dann noch der Blitterzugriff...

Die Festplatte ist gegen das RAM eine lahme Ente, hier spielen die genannten Dinge eine wesentliche Rolle. Nur zwischen ExAll und ExNext merkt man den Unterschied kaum, nur für den Programmierer sind "Superfunktionen" komfortabler, da weniger Schreibarbeit.

[ - Antworten - Zitieren - Direktlink - ]

-1-

[ - Beitrag schreiben - ]

amiga-news.de Forum > Programmierung > ExAll()?

[ - Suche - Neue Beiträge - Registrieren - Login - ]