Da Sie sagten, Plattform und Sprache spielen keine Rolle...
Wenn Sie eine stabile Leistung wünschen, die so schnell ist, wie es das Quellmedium zulässt, ist die einzige mir bekannte Möglichkeit, dies unter Windows zu erreichen, überlappende nicht-OS-gepufferte ausgerichtete sequenzielle Lesevorgänge. Mit zwei oder drei Puffern kann man wahrscheinlich einige GB/s erreichen, darüber hinaus braucht man irgendwann einen Ringpuffer (ein Schreiber, 1+ Leser), um jegliches Kopieren zu vermeiden. Die genaue Implementierung hängt von den Treibern/APIs ab. Wenn im Thread (sowohl im Kernel- als auch im Usermode), der sich mit der IO befasst, Speicher kopiert wird, wird natürlich umso mehr Zeit damit verschwendet, je größer der zu kopierende Puffer ist, anstatt die IO durchzuführen. Die optimale Puffergröße hängt also von der Firmware und dem Treiber ab. Unter Windows sind gute Werte ein Vielfaches von 32 KB für Festplatten-IO. Die Windows-Dateipufferung, die Speicherzuordnung und all diese Dinge verursachen zusätzlichen Aufwand. Dies ist nur dann sinnvoll, wenn mehrere Lesevorgänge (oder beides) für dieselben Daten im Direktzugriff durchgeführt werden. Wenn Sie also eine große Datei ein einziges Mal sequentiell lesen, möchten Sie nicht, dass das Betriebssystem irgendetwas puffert oder Memcpy's durchführt. Bei der Verwendung von C# gibt es auch Strafen für den Aufruf in das Betriebssystem aufgrund von Marshaling, so dass der Interop-Code möglicherweise Bit der Optimierung benötigen, es sei denn, Sie C++/CLI verwenden.
Manche Leute bevorzugen es, Probleme mit Hardware zu lösen, aber wenn man mehr Zeit als Geld hat, ist es in manchen Szenarien möglich, Dinge so zu optimieren, dass sie auf einem einzigen Computer auf Verbraucherniveau 100-1000 Mal besser funktionieren als auf 1000 Computern in Unternehmenspreisen. Der Grund dafür ist, dass, wenn die Verarbeitung auch latenzempfindlich ist, die Verwendung von mehr als zwei Kernen wahrscheinlich eine zusätzliche Latenz bedeutet. Aus diesem Grund können Treiber Gigabyte/s erreichen, während Unternehmenssoftware am Ende bei Megabyte/s stecken bleibt, wenn alles fertig ist. Was auch immer die Unternehmenssoftware an Berichten, Geschäftslogik und dergleichen leistet, kann wahrscheinlich auch mit Gigabytes/s auf einer Consumer-CPU mit zwei Kernen erledigt werden, wenn sie so geschrieben ist, als hätte man in den 80er Jahren ein Spiel geschrieben. Das berühmteste Beispiel, von dem ich gehört habe, dass die gesamte Geschäftslogik auf diese Weise entwickelt wurde, ist die Devisenbörse LMAX, die einen Teil ihres Ringpuffer-basierten Codes veröffentlicht hat, der angeblich von Netzwerkkartentreibern inspiriert wurde.
Vergessen Sie die ganze Theorie, wenn Sie mit < 1 GB/s zufrieden sind, ist ein möglicher Ausgangspunkt unter Windows der readfile-Quellcode von winimage, es sei denn, Sie wollen sich mit sdk/Treiberbeispielen beschäftigen. Möglicherweise sind einige Quellcodekorrekturen erforderlich, um die Leistung bei SSD-Geschwindigkeiten korrekt zu berechnen. Experimentieren Sie auch mit Puffergrößen. Die Schalter /h multi-threaded und /o overlapped (completion port) IO mit optimaler Puffergröße (probieren Sie 32, 64, 128 KB usw.) ohne Windows-Dateipufferung ergeben meiner Erfahrung nach die beste Leistung beim Lesen von SSD (kalte Daten) bei gleichzeitiger Verarbeitung (verwenden Sie /a für Adler-Verarbeitung, da es sonst zu CPU-gebunden ist).