Respondiendo a tu pregunta inicial, el acceso (lectura/escritura) a disco es mas costoso y posee mas latencia que el acceso a la DRAM, por lo que el manejo de datos sera mas rapido en RAM directamente que en un HDD/SSD. La respuesta obvia entonces seria que debes entonces cargar todo el fichero en memoria en lugar de leer "chunks" del disco?. Pues eso dependera de varios factores. Depende del tamaño del fichero que deseas manipular o de la eficiencia del uso de memoria que persigas o simplemente del diseño en particular que desees con tu software. Quizas puedes hacer como dices y leer todo el fichero en segmentos cada vez. Podrias tambien mapear el fichero en memoria y dejar que el SO maneje las paginas de memoria por ti, lo que podria llegar a ser mas rapido pero tambien puede tener sus dolores de cabeza.

Habiendo dicho lo anterior, creo que no estaria de mas hacerte algunas preguntas extras como:
- Que tan eficiente es tu diseño?. Cuan escalable? Podrias usar algun engine de bases de datos en lugar de "ficheros"?
- Estas seguro que la degradacion en rendimiento viene dada por esta situacion en particular? Haz usado algun "profiling tool" en tu codigo y confirmado lo anterior?
- Tu software usa o puede usar algun tipo de trabajo concurrente, procesamiento en paralelo? Multihilos?
- Podrias usar alguna libreria creada justamente con el fin de obtener el maximo rendimiento al leer grandes cantidades de datos en lugar de reinventar la rueda?

Tu buffer nunca precisa ser menor que el tamaño de un sector del disco.

Es decir crear un buffer de 256 o 512 bytes es practicamente ridículo ( a estas alturas, en los 80s sería bastante conforme).
Mínimo 4Kb. y preferentemente 64Kb. pero salvo que tengas una memoria muy reducida, mi recomendación es que apuntes a buffer de tamaño 1-8 mb.
En cualquier caso, usa siempre un valor de base binaria, no de valores arbitrarios.

La unidad del S.O. tiene un tamaño de sector que el propio S.O. elige, pero en las otras unidades cuando tu formateas conviene que le des el tamaño que mejor convenga conforme al tipo de ficheros que va a alojar... por ejemplo si una unidad va a contener películas y otros vídeos, un tamaño de sector de 32 o 64kb. es lo mas acertado... y si vas a tener chorrocientosmil ficheritos minúsculos, es preferible un tamaño de 4kb. como tamaño de sector.

La lectura de 1Gb. según el disco duro (doy por hecho que se trata de un HDD y no de un SSD), no debería demorar mas del rango 1-20sg (dependiendo del disco). De hecho sería conveniente hacer pruebas de rendimiento... crea un programa que lea 3-4 ficheros (distintos) de 1gb. empezando con un buffer de 4kb. y terminando (por ejemplo) con un búffer de 64Mb.
Lee primero el fichero-A con  el tamaño elegido y notas el tiempo al término, luego con el fichero-B, luego el fichero-C, etc... antes de saltar a otro tamaño (el objetivo es que no dejes usar la caché del disco duro, el primero opera con su tiempo y el resto se beneficien de dicha caché y por tanto falsifique el rendimiento real... saltando a distintos ficheros, prácticamente se imposibilita dicha situación).

Por último un rendimiento lento del disco se obtiene en algunas situaciones (así al vuelo se me vienen estas causas).
- Poco espacio libre en la unidad (se nota sobretodo al escribir, pero también al leer).
- Unidad muy fragmentada. Supone reposicionar el cabezal de lectura para leer cada sector, si el tamaño del sector es excesivamente pequeño, supone más reposicionamientos y por tanto más lentitud con ficheros muy grandes.
- El ingenioso hidalgo don virus de la Mancha... se emperra en mancharte tu rendimiento con cada lectura escritura.
- Alguna tarea programaa de monitoreo demasiada exhaustiva.
- Algún virus, u otro programa que se emperra en monitorear determinados procesos. Imagina un intruso minando bitcoin en tu equipo, por ejemplo...
- Disco siendo constantemente accedido por otros procesos en marcha.
- Demasiados procesos consumiendo recursos: memoria, CPU, etc...
- ...hay más factores, pero estos son los más habituales...