Hallo zusammen, während ich hier einem rotierenden Warte-Mauszeiger zusehe, drängt sich mir die Frage auf: Warum dauert die Suche nach Dateien auf einem Datenträger eigentlich so unglaublich lange, und warum rödelt die Festplatte so lange herum? Irgendwie deckt sich das nicht mit meinem (geringen) Verständnis, wie Dateisysteme funktionieren. Früher™ gab es eine FAT am Anfang der Partition. Lustigerweise finde ich keine Beschreibung, wie groß diese Tabelle eigentlich ist, aber die Größe wird ja klein im Verhältnis zu den Nutzdaten (Dateien) sein. Ich würde davon ausgehen, dass diese Tabelle komplett in den Hauptspeicher eines modernen PCs passt, und alles, was ich brauche, um eine Datei oder einen Ordner zu finden, sollte doch da drin stehen?
Die FAT ist nicht das Directory, sondern enthält nur den Belegtstatus und die Verkettung der einzelnen Blöcke.
:
Bearbeitet durch Moderator
Walter T. schrieb: > Hallo zusammen, > > während ich hier einem rotierenden Warte-Mauszeiger zusehe, drängt sich > mir die Frage auf: Warum dauert die Suche nach Dateien auf einem > Datenträger eigentlich so unglaublich lange, und warum rödelt die > Festplatte so lange herum? Irgendwie deckt sich das nicht mit meinem > (geringen) Verständnis, wie Dateisysteme funktionieren. > > Früher™ gab es eine FAT am Anfang der Partition. Lustigerweise finde ich > keine Beschreibung, wie groß diese Tabelle eigentlich ist, aber die > Größe wird ja klein im Verhältnis zu den Nutzdaten (Dateien) sein. Ich > würde davon ausgehen, dass diese Tabelle komplett in den Hauptspeicher > eines modernen PCs passt, und alles, was ich brauche, um eine Datei oder > einen Ordner zu finden, sollte doch da drin stehen? Versuche doch einfach auf deinem Rechner ein Betriebssystem zu nutzen, dass diesen Namen auch verdient
Die FAT ist für das Suchen von Dateien aber irrelevant. https://de.wikipedia.org/wiki/File_Allocation_Table Weiterführende Infos : https://de.wikipedia.org/wiki/Liste_von_Dateisystemen Nutzt du eine SSD oder HDD? Nur das Hauptverzeichnis befindet sich an einer definierten stelle alle Unterverzeichnisse nicht. Und diese können auch noch fragmentiert sein.
Yalu X. schrieb: > Die FAT ist nicht das Directory, sondern enthält nur den Belegtstatus > und die Verkettung der einzelnen Blöcke. Das heißt die Ordnerstruktur ist kein einzelner Block im Dateisystem, sondern auf viele, viele Blöcke verteilt, die auch noch kreuz und quer über den gesamten Datenträger verteilt sind? Obelix X. schrieb: > Nutzt du eine SSD oder HDD? Im Moment warte ich auf eine USB-HDD mit NTFS. Die Frage war also eher allgemeiner Natur. Ich gehe davon aus, dass FATx einfacher verständlich und NTFS komplizierter ist.
:
Bearbeitet durch User
Walter T. schrieb: > Das heißt die Ordnerstruktur ist kein einzelner Block im Dateisystem, > sondern auf viele, viele Blöcke verteilt, die auch noch kreuz und quer > über den gesamten Datenträger verteilt sind? Ja. Walter T. schrieb: > Ich gehe davon aus, dass FATx einfacher verständlich > und NTFS komplizierter ist. Ja.
Das ist ja nichts neues, wusste schon Niklaus Wirth (RIP) https://de.wikipedia.org/wiki/Wirthsches_Gesetz Es gibt aber Sofware die zeigt, dass es auch anders gehen kann. Etwa WizTree, die liest ein 200 GByte NTFS Dateisystem auf einer SSD in 2 Sekunden ein. Das Kommandozeilentool robocopy ist auch ziemlich schnell beim kopieren. Im Open Source Zeitalter zahlt halt keiner was für (performante) Software, entsprechend ist die Motivation der Programmierer, you get what you paid...
Du könntest z.b. die Laufwerksindizierung aktivieren, dann geht die Suche ganzer Laufwerke innerhalb von Sekunden. Wind10->Startmenü->"Indizierungsoptionen"
Wladimir schrieb: > Versuche doch einfach auf deinem Rechner ein Betriebssystem zu nutzen, > dass diesen Namen auch verdient Erspare mir doch einfach deine Kommentare, wenn du nichts zu Sache zu sagen hast.
Ich habe an dieser Stelle kein echtes Geschwindigkeitsproblem. Nur Zeit zum Nachdenken. WizTree sieht aber trotzdem interessant aus. Von der Aufgabenstellung scheint es ja für ähnliche Zwecke wie WinDirStat oder Sequoia angesiedelt zu sein. Wenn es davon eine schnelle Version gäbe, wäre das natürlich dufte. Also danke für den Tipp. Beim Ordner durchsuchen scheint es aber auch nur wieder die Explorer-Suche zu bemühen.
:
Bearbeitet durch User
Manchmal ist die Explorersuche dumm und sucht nach dem Namen auch innerhalb von Dateien oder Zips. Mit name:xxx kann man die Suche erleichtern.
Walter T. schrieb: > Ich gehe davon aus, dass FATx einfacher verständlich > und NTFS komplizierter ist. FAT ist älter und damit weniger optimiert. NTFS ist daher schneller in allem und sicherer.
Peter D. schrieb: > FAT ist älter und damit weniger optimiert. NTFS ist daher schneller in > allem und sicherer. Ich erinnere mich dunkel an eine Zeit, als zu FAT geraten wurde, um die beste Performanz er erzielen. Das leuchtet ja auch ein: bei NTFS müssen bei jedem Dateizugriff erstmal die Benutzer- und Gruppenberechtigungen geprüft werden, während FAT diese Informationen gar nicht führt und das Betriebssystem daher auch keine Prüfungen durchführen muß. Insofern wundere ich mich ein wenig, daß Du jetzt sagst, NTFS sei schneller. Hast Du das selbst einmal ausgemessen?
Walter T. schrieb: > Ich habe an dieser Stelle kein echtes Geschwindigkeitsproblem. Nur Zeit > zum Nachdenken. > > WizTree sieht aber trotzdem interessant aus. Von der Aufgabenstellung > scheint es ja für ähnliche Zwecke wie WinDirStat oder Sequoia > angesiedelt zu sein. Wenn es davon eine schnelle Version gäbe, wäre das > natürlich dufte. Also danke für den Tipp. > > Beim Ordner durchsuchen scheint es aber auch nur wieder die > Explorer-Suche zu bemühen. Für NTFS empfehle ich Everything. Das findet so schnell wie du den Suchbegriff eintippst und ist so etwa 10^12 mal besser als die Windows Explorer-Suche!
Wenn du die Suche ein zweites Mal startest, sollte sie deutlich schneller vonstatten gehen, weil dann die relevanten Blöcke bereits im RAM gecachet sind. Dort bleiben sie aber nicht ewig. Sobald das OS meint, die belegten RAM-Blöcke sinnvoller nutzen zu können, werden sie überschrieben. Hab's gerade mal auf einer rotierenden Laptopfestplatte mit ext4 unter Linux getestet: Nach dem Löschen des Hauptspeicher-Caches dauert die erste Suche 82-mal so lang wie die zweite. Auf eine externen USB-3-Festplatte ist der Faktor sogar 474. Auf der internen SSD ist der Faktor erwartungsgemäß kleiner, nämlich nur 17.
Walter T. schrieb: > Warum dauert die Suche nach Dateien auf einem > Datenträger eigentlich so unglaublich lange, und warum rödelt die > Festplatte so lange herum? Na ja, entweder ist deine Festplatte zu langsam, oder dein InterfaceController für die Festplatte zu langsam... wenn deine Southbridge bzw. dein Controller bloß 200MB/s schafft, hilft dir auch die schnellste SSD nix
Ein T. schrieb: > Insofern wundere ich mich ein wenig, daß Du jetzt sagst, NTFS sei > schneller. Hast Du das selbst einmal ausgemessen? NTFS kann halt kleine Dateien direkt in der Verzeichnisstruktur unterbringen, und das mag Geschwindigkeitsvorteile mit sich bringen. Rechteauswertung ist kein relevanter Zeitfaktor gegenüber den eigentlichen Datenträgerzugriffen, vor allem, wenn auch noch eine mechanische Festplatte im Spiel ist. Die ist insbesondere beim Kopfpositionieren episch langsam. NTFS bietet schon sehr lange eine transparente Dateikompression, und die war zumindest beim Lesen schon zu 486er-Zeiten schneller als das direkte Lesen von einer Festplatte, was einem die Größenordnungen zwischen Rechenleistung und I/O-Durchsatz vor Augen führen sollte. Seitdem sind zwar Festplatten schneller geworden, aber das nur mit relativ geringen Faktor. MFM-Festplatten erreichten 500 kByte/sec Datenrate, heutige Festplatten erreichen 250 MByte/sec, das ist also gerade mal Faktor 500. Als NTFS mit Kompression eingeführt wurde, konnten Festplatten schon mehrere MByte/sec erreichen. Wieviel mal schneller aber sind in den letzten 30 Jahren PCs geworden?
Walter T. schrieb: > Warum dauert die Suche nach Dateien auf einem > Datenträger eigentlich so unglaublich lange, und warum rödelt die > Festplatte so lange herum? Weil Windows doof ist. Linux kann das viel schneller - auch auf FAT und NTFS. Auch die Zugriffe auf Dateiinhalte sind unter Windows auffällig langsamer. Ich vermute, das ist der Haupt-Grund für langsame Installationen von Updates. Der Dateimanager (Explorer) setzt noch einen drauf. Mit dem Xcopy Befehl kann man zum Beispiel viele Dateien erheblich schneller kopieren, als mit dem Dateimanager - warum auch immer. > Ich würde davon ausgehen, dass diese Tabelle komplett in den Hauptspeicher > eines modernen PCs passt Im Prinzip ja, aber das Inhaltsverzeichnis hat eine Baumartige Struktur, wobei jedes Blatt woanders gespeichert ist. Deswegen kann man das Inhaltsverzeichnis nicht mal eben schnell an einem Stück laden.
:
Bearbeitet durch User
Ein T. schrieb: > Insofern wundere ich mich ein wenig, daß Du jetzt sagst, NTFS sei > schneller. Hast Du das selbst einmal ausgemessen? Zu Windows-XP Zeiten waren viele USB-Sticks noch FAT formatiert. Insbesondere bei vielen kleinen Dateien rödelte sich dann XP zu Tode und der Stick wurde heiß. FAT ist quasi eine verkettete Liste, d.h. für jeden neuen Sektor muß wieder erstmal die FAT abgeklappert werden. Je nach Fragmentierung dauert das umso länger. FAT unterstützt auch keine langen Dateinamen, die werden in versteckten Verzeichniseinträgen abgelegt, die dann wieder verkettet werden. Ich habe seit über 20 Jahren kein FAT-Medium mehr eingelesen. Ob unter W10/W11 dafür noch was optimiert wurde, würde ich stark bezweifeln. Seit W10 kann man schon keine Disketten mehr einlesen.
Gunnar F. schrieb: > Für NTFS empfehle ich Everything. Kann ich auch nur empfehlen. Die Indexierung am Anfang dauert ein paar Sekunden. Danach wird alles so schnell gefiltert, wie man tippt. Es bietet übrigens auch eine Suchsyntax, so kann man z.B. mit 'folder:' nur nach Ordner suchen, oder mit 'file:' nur nach Files mit dem entsprechenden Namen nach dem Doppelpunkt. Die Windows Explorer Suche ist einfach Schnarchlangsam, trotz Indexierung.
Speziell bei der Suche nach Dateien anhand ihres Namens haben die FAT-Dateisysteme den Vorteil, dass bis zu 1024 Verzeichniseinträge in einem 32KiB-Cluster untergebracht werden können. Die Dateisuche kann also bis zu 1024 Namen in einem Rutsch einlesen, während bei anderen Dateisystemen für die gleiche Aktion der Lesekopf bis zu 1023-mal umpositioniert und jeweils im Mittel eine halbe Plattenumdrehung gewartet werden muss, was schon mal 5 bis 10 Sekunden dauern kann. In der Praxis wird ein Verzeichnis zwar selten 1024 Dateien enthalten, aber ein (kleinerer) Geschwindigkeitsvorteil ergibt sich schon ab 2 Dateien pro Verzeichnis.
Peter D. schrieb: > Zu Windows-XP Zeiten waren viele USB-Sticks noch FAT formatiert. > Insbesondere bei vielen kleinen Dateien rödelte sich dann XP zu Tode und > der Stick wurde heiß. Kann ich nicht bestätigen. FAT war hier (früher) immer deutlich schneller als NTFS. Das hat wesentlich weniger Overhead und die Treiber sind einfacher und die Programmierer wussten damals noch die x86 Register auswendig. Da hat sich auch nie was zu Tode gerödelt oder ist heiss geworden. Mit den Beschränkungen konnte man als PC Benutzer bis zum Aufkommen von HD-Videos gut leben.
Steve van de Grens schrieb: > Weil Windows doof ist. Linux kann das viel schneller - auch auf FAT und > NTFS. Auch die Zugriffe auf Dateiinhalte sind unter Windows auffällig > langsamer. Ich vermute, das ist der Haupt-Grund für langsame > Installationen von Updates. Irgendwie kann ich den ewigen Linux Blödsinn hier nicht mehr lesen. Lernt man heute nichts mehr? So blöd kann man selbst heute nicht programmieren, um die paar MB/Sekunde nicht zu liefern, die ein USB Stick lesen oder schreiben kann. Und die Treiber sind steinalt, da wurden damals alle möglichen Tricks gemacht, um etwa die Zugriffszeiten auf die HDD zu minimieren. Linux hat ein recht aggressives Caching und Speichermanagement - passend zu den aggressiven Benutzern. Windows ist gemütlicher, passend für die Masse und dreht das Caching ab, es haben schon genug den USB Stick beim rausziehen geschrottet.
Peter D. schrieb: > Ich habe seit über 20 Jahren kein FAT-Medium mehr eingelesen Du hast also in den letzten 20 Jahre keine einzige SD Karte benutzt? Glaube ich Dir nicht. SD Karten sind standardmäßig immer FAT formatiert, weil das nach Norm so vorgesehen ist. Microsoft hat dafür sogar extra nochmal ein neues FAT System konstruiert (natürlich mit Patentschutz...): https://en.wikipedia.org/wiki/ExFAT
Peter D. schrieb: > Manchmal ist die Explorersuche dumm und sucht nach dem Namen auch > innerhalb von Dateien oder Zips. > Mit name:xxx kann man die Suche erleichtern. Meine Explorer-Suche ist momentan komplett kaputt. Wenn ich nach '.svn art:folder' suchen will, macht mir erst einmal eine Rechtschreibkorrektur den Suchstring kaputt (wird zu '.svnrt:folder'). Ich habe die Rechtschreibkorrektur in Windwos allerdings ausgeschaltet. Und selbst nach der Korrektur findet er plötzlich auch RAR-Dateien wie 'ABC_SVN.rar', die nun wirklich keine Ordner sind. Deswegen nutze ich momentan die Dateisuche von Notepad++. Ist aber irgendwie Off-Topic.
Udo K. schrieb: > Kann ich nicht bestätigen. FAT war hier (früher) immer deutlich > schneller als NTFS. Das originale FAT(16) gabs auf Festplatten, die in MB gemessen wurden. Deren Suchgeschwindigkeiten mit aktuellen NTFS-Platten mit TBs zu vergleichen, ist dann doch etwas Äpfel und Birnen. Oliver
Udo K. schrieb: > Linux hat ein recht aggressives Caching und Speichermanagement - passend > zu den aggressiven Benutzern. > Windows ist gemütlicher, passend für die Masse und dreht das Caching ab, > es haben schon genug den USB Stick beim rausziehen geschrottet. Ja, der Windows Nutzer ist im allgemeinen auch eher gemütlich unterwegs. Während der Linuxer am Montag mit dem Projekt fertig ist und den Rest der Woche genießt wartet der Windowser am Freitag immer noch darauf das er seine Dateien findet ;-) Gefühlt sind Dateizugriffe unter Linux tatsächlich etwas schneller, vor allem bei kleinen Dateien. Wir haben hier unter Windows dazu massive Performanceeinbrüche beim Kompilieren die nachweislich durch den Virenscanner entstehen. Der Scannerhersteller hat von uns sogar ein Test PC zum Entwickeln /Fehlersuchen bekommen. Es gibt übrigens die "flush" mount option. Mit der wird das caching etwas zurückgefahren.
Udo K. schrieb: > Irgendwie kann ich den ewigen Linux Blödsinn hier nicht mehr lesen. > Lernt man heute nichts mehr? So blöd kann man selbst heute nicht > programmieren Erzähle das Microsoft! Das Linux bei Dateizugriffen generell besser performt, ist kein "ewiger Linux Blödsinn" sondern ein trauriger Fakt. Ich kann nichts dafür, dass Microsoft diesen Teil schlechter programmiert hat. > Linux hat ein recht aggressives Caching und Speichermanagement - passend > zu den aggressiven Benutzern.Windows ist gemütlicher, passend für die Masse > und dreht das Caching ab. Das Verhalten des Schreib-Caches ist nach meinem Kenntnisstand in beiden Betriebssystemen konfigurierbar. Hier geht es aber weder um Schreibzugriffe, noch um externe Medien (wo Windows per Default weniger Schreibcache verwendet).
:
Bearbeitet durch User
Beitrag #7573487 wurde vom Autor gelöscht.
Steve van de Grens schrieb: > Erzähle das Microsoft! Das Linux bei Dateizugriffen generell besser > performt, ist kein "ewiger Linux Blödsinn" sondern ein trauriger Fakt. > Ich kann nichts dafür, dass Microsoft diesen Teil schlechter > programmiert hat. Hat übrigens auch rein gar nichts mit Linux zu tun. Alle unixoiden OSe sind beim Dateihandling um Welten schneller – was auch immer MS da verbockt hat. Wie schon genannt worden ist, beim Compilieren größerer Projekte wird das sehr schnell offensichtlich (auch ohne Virenchecker).
Unter Windows funktioniert Agent Ransack ( heisst wirklich so ) zuverlässig und erträglich schnell. https://www.mythicsoft.com/agentransack/download/ Unter Linux geht suchen, ersetzen, zusammenstückeln, ect ... auf der console mit find, grep, cat, ffmpeg, ... blitzeschnell.
Andreas M. schrieb: > Du hast also in den letzten 20 Jahre keine einzige SD Karte benutzt? Zumindest nicht direkt. Falls sowas in einem Gerät stecken sollte, dann greife ich per USB-Kabel oder WLAN drauf zu. Ich könnte nicht mal sagen, wo sich der Kartenleser im PC/Notebook befindet. Vorhanden sein wird vermutlich einer. Der SD-Slot im Handy ist leer, die internen 128GB werden wohl ewig reichen.
ich benütze unter win7 "masterseeker" und das geht echt fix. https://www.computerbild.de/download/MasterSeeker-18841241.html
Jörg W. schrieb: > Hat übrigens auch rein gar nichts mit Linux zu tun. Alle unixoiden OSe > sind beim Dateihandling um Welten schneller – was auch immer MS da > verbockt hat. Wie schon genannt worden ist, beim Compilieren größerer > Projekte wird das sehr schnell offensichtlich (auch ohne Virenchecker). Das ist die Anwendersicht. Der wichtige Punkt ist, dass das wenig bis nix mit dem Betriebssystem Kernel zu tun hat, sondern nur mit Anwenderprogrammen und Schichten dazwischen. Kein OS begrenzt die Performance der HW wesentlich, da werden einfach nur Blöcke geschrieben, das ganze geht heute ohne das die CPU was macht. Alles läuft in HW parallel am OS vorbei mittels DMA, da werden nur ein paar Register gesetzt. Selbst das Verschlüsseln kostet keine Performance, weil auch das HW macht. Das Filesystem hat einen kleinen Effekt, wenn es etwa kleine Files ineffizient speichert. HP-UX etwa habe ich in den 90'ern regelmässig mit 1000'den Simulationsfiles in einem einzigen Verzeichnis lahmgelegt, keine Ahnung was das Filesystem da war. Bei mir (Win10) etwas läuft der clang-cl und der gcc Compiler im Vergleich zum MS cl deutlich langsamer (2-3x). Ich weiss aber, das der unter Linux deutlich schneller ist. Offensichtlich liegt es an irgendwelchen libc Optimierungen, die unter Windows nicht gut portiert sind. Die Performance vom Windows Explorer ist aber inzwischen wirklich abartig, aber was solls, für den Normalverbraucher reichts. Dafür löscht der keine Daten, sondern kopiert sie irgendwohin, damit ein Ctrl-Z das ganze Rückgängig macht.. Hier ein interessanter Vortrag von Robert Collins, der hat sich mit den Dingen mal intensiv beschäftigt: https://www.reddit.com/r/programming/comments/vjqrye/ntfs_really_isnt_that_bad_robert_collins_lca_2020/ Ich verlinke auch mal den Thread Beitrag "Re: c++ Code langsam" Da sieht man schön, dass das BS im Vergleich zum Programmierer und den verwendeten Libs vernachlässigbar ist. Ich vermisse das gute alte XP. Das hatte ich diese Woche in einer vmware installiert, und einige Tests gemacht. Etwa das Timing von LoadLibraryEx: 200 uS in XP, 500 uS in Win10, ok ist hier nicht wichtig.
:
Bearbeitet durch User
Udo K. schrieb: > Das ist die Anwendersicht. Das ist mir als Anwender völlig egal. :-) > Der wichtige Punkt ist, dass das wenig bis > nix mit dem Betriebssystem Kernel zu tun hat, sondern nur mit > Anwenderprogrammen und Schichten dazwischen. Zumindest die Anwenderprogramme sind beim Compilieren die gleichen: Compiler, Assembler, Linker, make oder vergleichbar. Ich rede hier nicht von irgendwelchen IDEs. Daran allein kann es also nicht liegen. Die "Schichten" darunter gehören dann nun schon mal zum Betriebssystem, ob das nun Kernel oder Library ist, kann mir als Anwender wurscht sein. Ein Compiler ist ja ein relativ simples Anwenderprogramm, welches in allererster Linie Dateien verarbeitet. Das Einzige, was darin überhaupt OS-abhängig ist, wäre der Aufruf der individuellen Tools (Assembler und Linker), die als externe Prozesse gestartet sind. Gut, dass das Erstellen eines Prozesses unter Windows vergleichsweise teuer ist (bei den Unixen unterscheiden sich Prozesse und Threads im Aufwand so gut wie gar nicht, oft gehen sie mittlerweile auf das gleiche Backend im Kernel), mag noch ein Argument sein, aber das erklärt die Lahmheit im Umgang mit vielen Dateien unter Windows zumindest nicht 100%ig. > Bei mir (Win10) etwas läuft der clang-cl und der gcc Compiler im > Vergleich zum MS cl deutlich langsamer (2-3x). Ich weiss aber, das der > unter Linux deutlich schneller ist. Offensichtlich liegt es an > irgendwelchen libc Optimierungen, die unter Windows nicht gut portiert > sind. Was soll denn ein Compiler da groß brauchen? Das Einzige wäre noch die Speicherverwaltung. Ein Compiler liest Dateien, macht was damit, und schreibt Dateien. Dass sich andere Compiler insgesamt anders verhalten, ist kein guter Vergleich. Als Vergleich müsstest du diese Compiler dann auch auf anderen Plattformen laufen lassen (können). > Die Performance vom Windows Explorer ist aber inzwischen wirklich > abartig, aber was solls, für den Normalverbraucher reichts. Dafür > löscht der keine Daten, sondern kopiert sie irgendwohin, damit ein > Ctrl-Z das ganze Rückgängig macht.. Das machen Dateimanager auf anderen Systemen genauso, das ist kein Argument – performancemäßig schon gar nicht, denn für dieses Nicht-Löschen muss man ja die Dateidaten selbst nicht anfassen, man schiebt nur Verzeichniseinträge. Erst das richtige Löschen braucht dann (bei größeren Datenmengen) wieder Zeit. > https://www.reddit.com/r/programming/comments/vjqrye/ntfs_really_isnt_that_bad_robert_collins_lca_2020/ NTFS ist für seine Zeit sicher nicht schlecht. Stammt ja auch nicht von Microsoft :), war eigentlich mal HPFS, was sie zusammen mit IBM für OS/2 entwickelt haben. Aus heutiger Sicht gibt es natürlich besseres.
Ich hatte mal ein kostenpflichtiges Windows Programm, mit dem man DVDs Entschlüsseln und kopieren konnte. Dieses lief unter Linux im WINE Emulator doppelt so schnell, wie unter Windows. Später ist mir ein ähnlich krasser Unterschied beim Programmieren mit Java (SAP E-Commerce) aufgefallen. In der Schulung konnte die Übungsaufgaben nicht machen, weil mein Laptop zu langsam war. Der entscheidende Unterschied war: Die anderen Teilnehmer hatten alle Linux, ich hatte Windows.
Walter T. schrieb: > Früher™ gab es eine FAT Also DOS/Win und Verwandschaft... > Warum dauert Dateisuche eigentlich so lange? "everything" fängt schnell das Ding! https://www.voidtools.com/ los mit DOS 1979: https://www.golem.de/news/86-dos-alter-vorgaenger-von-ms-dos-wurde-gefunden-2401-180759.html FAT: Ebenfalls 1979 wurde Standalone Disk BASIC-86 von Bob O’Rear auf eine von Seattle Computer Products (SCP) entwickelte S-100-Bus-Hardware-Plattform angepasst. Bei dieser Gelegenheit wurde Tim Paterson auf das Dateisystem aufmerksam, das er 1980 als konzeptionelle Grundlage seines 12-Bit-Dateisystems für SCPs Betriebssystem QDOS wählte, welches, umbenannt in 86-DOS, von Microsoft zunächst lizenziert, aufgekauft und daraufhin 1981 die Ausgangsbasis für MS-DOS und PC DOS 1.0 wurde. Quelle: de:WP (frei)
Udo K. schrieb: > Jörg W. schrieb: >> Hat übrigens auch rein gar nichts mit Linux zu tun. Alle unixoiden OSe >> sind beim Dateihandling um Welten schneller – was auch immer MS da >> verbockt hat. Wie schon genannt worden ist, beim Compilieren größerer >> Projekte wird das sehr schnell offensichtlich (auch ohne Virenchecker). > > Das ist die Anwendersicht. Der wichtige Punkt ist, dass das wenig bis > nix mit dem Betriebssystem Kernel zu tun hat, sondern nur mit > Anwenderprogrammen und Schichten dazwischen. Das besagte Verhalten tritt allerdings nicht nur beim Kompilieren auf, sondern läßt sich auch bei anderen Anwendungsfällen, und bei synthetischen Benchmarks beobachten. Die Wahrscheinlichkeit, daß das nichts mit dem "Betriebssystem Kernel zu tun hat", liegt daher nahe Null. Ein ähnliches Verhalten zeigt sich im Übrigen auch bei Speicherzugriffen. Während Windows XP sowie Windows8 und seine Nachfolger etwa 30% langsamer waren als unterschiedliche Linux-Distributionen auf derselben Hardware, hat Windows7 mit 50% sogar den Vogel abgeschossen, konsistent über Allokation, Deallokation und Operationen. Und, ach so: alles natürlich ohne Virenscanner gemessen, mit Virenscanner sieht Windows sicher noch schlechter aus. Keine Ahnung, was Microsoft da macht, allerdings... ihr Betriebssystem hat wohl andere Entwicklungsziele zu haben, als die maximale Leistung aus der Hardware herauszuholen. Naja, da ist Microsoft in guter Gesellschaft. ;-)
Für NTFS-Datenträger, die man nur mal eben ansteckt, geht das klasse mit Ultrasearch https://www.jam-software.de/ultrasearch Das muss keinen Index aufbauen und lädt direkt die NTFS-Dateiliste, auch portabel. Also starten und suchen auch auf fremden Rechnern in Sekunden. Wenn man dauerhaft auf seinem Rechner öfter mal was sucht ist Everything https://www.voidtools.com/support/everything/ das Mittel der Wahl, damit klappts auch bei Netzwerklaufwerken o.ä., aber Everything muss einen eigenen Index aufbauen, was ab und an gemacht werden sollte und dauert (kann auch automatisch im Hintergrund passieren). Die Suche ist aber "live", also während des tippens schon da.
Ein T. schrieb: > Keine Ahnung, was Microsoft da macht, Hi, also das musste ich aufpieksen, weil die Dinge eher so sind: Unix-Tools ziemlich gut, teilweise von Leuten wie Aho oder den Entwicklern der C-Programmiersprache erstellt, und von gewissen Leuten drumherum. Das sagt schon so einiges. Außerdem war Unix schon immer bei der Parallelprogrammierung am Ball, während Bill Gates zwar ein guter Basic-Programmierer und Geschäftsmann ist, darüberhinaus aber auch eher BWLer als Programmierer. Linux ist auch lustig, beispielsweise bekommt man bei Ripgrep auch gleich sowas wie "..hey, guckstu hier, heißer scheiss, nimmst du mit? um die Ohren gehauen..so dass man ohne viel zu tun auch gleich eine brauchbare Rust-Entwicklungsbasis im System hat. (weswegen ich damals so lachen musste, weil die Rust-Installation bei Windows so ein unwürdiges Gewürge ist. Haskell ist da eigentlich auch nicht viel besser..) Außerdem gibt es bei Windows vor allem nur Notepad - während bei Unix viel über den Emacs läuft. Das sagt doch auch schon so einiges. https://stackoverflow.com/questions/76666894/how-to-install-ripgrep-on-windows
Mal völlig unabhängig von Betriebssystem und Dateisystem: Der Datenträger als solcher ist für die Suche etwa so, als wenn man einen Tisch voller Ordner und Zettel hat. Wenn man keine Ahnung hat wo das gesuchte Dokument sein könnte, muss man jedes einzeln anschauen. So geht das der Suchfunktion, wenn kein Suchindex erstellt wurde. Hat man ordentlich beschriftete Ordner mit einem Inhaltsverzeichnis in jedem Ordner, dann geht die Suche viel schneller. Der Suchindex ist quasi wie ein strukturiertes Inhaltsverzeichnis. Das wird vorher erstellt (da gibt es unterschiedliche Strategien, einige Systeme tun das ständig im Hintergrund). Wenn dann eine Suchanfrage kommt, hat das System ein Verzeichnis in dem gewissermaßen drin steht "Dateien mit dem Namen Karl finden sich in den Ordnern 5, 17, 93", dann guckt die Suchfunktion noch in das Inhaltsverzeichnis dieser drei Ordner und präsentiert das Ergebnis. Also unabhängig vom Betriebssystem und Dateisystem: Suchindex erstellen lassen, wie auch immer das auf der jeweiligen Plattform geht. Und nun bitte weiter streiten, ob Sandale oder Flasche. Ich nehme Äpfel ;)
Guido K. schrieb: > Wenn man keine Ahnung hat wo das > gesuchte Dokument sein könnte, muss man jedes einzeln anschauen. Wenn man Glück hat, könnte man einen Pop-Out Effekt erleben. Inhaltsaddressierung und Ordnung (Wiederholung) ist immer hilfreich, so war es früher u.a. empfehlenswert, seine Videokassetten gut zu beschriften. Inhaltsaddressierung an sich und Ordnung kann man noch unterscheiden die erstere ist eher ein Zeiger, die letzte eher eine Sortier- und Workflowfrage. Zeiger hat man bei vielen wissenschaftlichen Publikationen, was eher ein Übel ist, weil man oft nicht drumherum kommt, die genannten Referenzen selber gut nachzulesen. Toll, wenn die dann auch vorrangig viel aus Zeigern bestehen. Aktuell gibt es einige Bücher, die sind so drauf. Ohne eigene (Erfahrung-)Referenzen kaum lesbar oder nutzbar. An der Uni gab es manchmal Überblicksartikel die halfen. Hatte man die nicht, konnten Fachlexika ein wenig weiterhelfen. Bei Computern gibt es Algos, die helfen, Muster zu finden oder zu sortieren. Binäre Suche zum Beispiel, oder der Einsatz von Parallelisierung oder von FSMs. https://de.wikipedia.org/wiki/Aho-Corasick-Algorithmus Bei Windows hatte früher auch Defragmentieren geholfen, oder die Größe der Auslagerdatei auf feste Werte zu stellen.
Walter T. schrieb: > diese Tabelle komplett in den Hauptspeicher > eines modernen PCs passt, und alles, was ich brauche, um eine Datei oder > einen Ordner zu finden Sicher würde das gehen. Aber das wäre viel zu einfach. Gerade im PC Bereich wird alles möglichst umständlich und so schlecht gemacht das er blos schnell zu langsam wird. So können dann SSDs und schnellere PCs verkauft werden.
Guido K. schrieb: > Also unabhängig vom Betriebssystem und Dateisystem: Suchindex erstellen > lassen, wie auch immer das auf der jeweiligen Plattform geht. In Windows wird der Index standardmäßig automatisch erstellt. Nur blöd, dass die Suche im Explorer trotz Index oft langsamer ist, als in Linux ohne Index. Ich hatte auch manchal das Problem, dass Windows einzelne Dateien nicht gefunden hat, obwohl sie ganz sicher existierten und lesbar waren. Meine Kollegin ebenso.
:
Bearbeitet durch User
Gunnar F. schrieb: > Für NTFS empfehle ich Everything. Das findet so schnell wie du den > Suchbegriff eintippst und ist so etwa 10^12 mal besser als die Windows > Explorer-Suche! Everything kann auch FAT, man muß sie manuell als Ordner eintragen. Aber man muß eh an den Einstellungen drehen, damit es den persönlichen Vorlieben nahe kommt. Operator S. schrieb: > Es bietet übrigens auch eine Suchsyntax, so kann man z.B. mit 'folder:' > nur nach Ordner suchen, oder mit 'file:' nur nach Files mit dem > entsprechenden Namen nach dem Doppelpunkt. Man kann im GUI unter "Suche - Erweiterte Suche" Bedingungen eintragen und sieht dann, wie sich die Suchzeile aufbaut. Ein paar Mal angeschaut, lernt man so, es ohne GUI zu nutzen. Walter T. schrieb: > Meine Explorer-Suche ist momentan komplett kaputt. Aus meiner Sicht wurde der Windows-Explorer ab Vista zunehmend verbastelt und immer unbrauchbarer. Die Suche unter Win10 finde ich unbenutzbar. War nicht das erste Mal, dass ich die Kommandozeile bemühe:
1 | D:\>dir /s ever*.??? |
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.