No creo que haya nada dentro de .NET para permitir la copia de una sección de un archivo sin búfer en la memoria. Sin embargo, me parece que esto es ineficiente de todos modos, ya que necesita abrir el archivo de entrada y buscar muchas veces. Si usted es simplemente dividir el archivo, por qué no abrir el archivo de entrada una vez, y luego simplemente escribir algo como:
public static void CopySection(Stream input, string targetFile, int length)
{
byte[] buffer = new byte[8192];
using (Stream output = File.OpenWrite(targetFile))
{
int bytesRead = 1;
// This will finish silently if we couldn't read "length" bytes.
// An alternative would be to throw an exception
while (length > 0 && bytesRead > 0)
{
bytesRead = input.Read(buffer, 0, Math.Min(length, buffer.Length));
output.Write(buffer, 0, bytesRead);
length -= bytesRead;
}
}
}
Esta ineficiencia tiene una menor importancia en la creación de un búfer en cada invocación - es posible que desee para crear el buffer de una vez sucedió que en el método, así:
public static void CopySection(Stream input, string targetFile,
int length, byte[] buffer)
{
using (Stream output = File.OpenWrite(targetFile))
{
int bytesRead = 1;
// This will finish silently if we couldn't read "length" bytes.
// An alternative would be to throw an exception
while (length > 0 && bytesRead > 0)
{
bytesRead = input.Read(buffer, 0, Math.Min(length, buffer.Length));
output.Write(buffer, 0, bytesRead);
length -= bytesRead;
}
}
}
Tenga en cuenta que esto también cierra el flujo de salida (debido a la instrucción using), que a su código original no lo hizo.
Lo importante es que esto utilizará el almacenamiento en memoria intermedia del archivo del sistema operativo de manera más eficiente, ya que reutilizará el mismo flujo de entrada, en lugar de volver a abrir el archivo al principio y luego buscar.
Yo creo que va a ser significativamente más rápido, pero es obvio que necesita para probarlo a ver ...
Esto supone trozos contiguos, por supuesto. Si necesita omitir partes del archivo, puede hacerlo desde fuera del método. Además, si está escribiendo archivos muy pequeños, es posible que también desee optimizarlos para esa situación: la forma más sencilla de hacerlo sería introducir un BufferedStream que envuelva el flujo de entrada.
File.OpenRead y 100.000 File.OpenWrite estará bien lento ... –
¿Está dividir el archivo a la perfección, es decir, se puede reconstruir el archivo de gran tamaño con sólo unirse a todos los pequeños archivos juntos? Si es así, hay ahorros para tener allí. Si no, ¿se superponen los rangos de los archivos pequeños? ¿Están ordenados por orden de compensación? – jamie