La creazione e la scrittura su un file di grandi dimensioni è più veloce rispetto alla creazione e scrittura in molti file più piccoli in Python su Linux?

Naviga le tue risposte
1

Se si utilizza Python su una macchina Linux, quale delle seguenti sarebbe più veloce? Perché?

  1. Creazione di un file all'inizio del programma, scrittura di grandi quantità di dati (testo), chiusura, quindi divisione del file di grandi dimensioni in molti file più piccoli alla fine del programma.
  2. Durante lo span del programma, verranno creati molti file più piccoli, scritti e chiusi.

In particolare, il programma in questione è uno che ha bisogno di registrare lo stato di un array molto grande in ognuna delle molte fasi temporali. Lo stato dell'array ad ogni passo temporale deve essere registrato in file indipendenti.

Ho lavorato con C su Linux e so che aprire / creare e chiudere i file costa molto tempo, e meno operazioni di apertura / creazione significano programmi più veloci. Lo stesso vale se si scrive in Python? Cambiare la lingua è importante anche se si utilizza ancora lo stesso sistema operativo?

Sono interessato anche al ruolo della RAM in questo contesto. Ad esempio, correggimi se ho torto, sto assumendo che parti di un file in fase di scrittura verranno inserite nella RAM. Se il file diventa troppo grande, aumenterà la RAM e causerà problemi di velocità o di altre aree? Se una risposta potrebbe incorporare RAM che sarebbe grande.

    
posta LazerSharks 27.08.2014 - 09:02
fonte

2 risposte

4

Per rispondere alla tua domanda, dovresti davvero fare un punto di riferimento (cioè misurare il tempo di esecuzione di diverse varianti del tuo programma). Suppongo che dipenda dal numero di piccoli file necessari (10 mila file non equivalgono a 10 miliardi di file) e dal file system che si sta utilizzando. Potresti usare tmpfs file system. Dipende ovviamente anche dall'hardware (i dischi SSD sono più veloci).

Vorrei anche suggerire di evitare di mettere un sacco di file nella stessa directory. Quindi preferisci dir01/file001.txt ... dir01/file999.txt dir02/file001.txt ... a file00001.txt ... file99999.txt ie hai directory con ad es. al massimo un migliaio di file.

Vorrei anche evitare di avere un sacco di piccoli file (ad esempio file con meno di cento byte di dati ciascuno): rendono un sacco di filesystem infelici (dal momento che un file ha almeno il suo inode ).

Tuttavia, dovresti forse prendere in considerazione altre alternative, come l'uso di un database (che potrebbe essere semplice come Sqlite ...) o l'uso di alcuni indicizzati file (come gdbm ...)

Per quanto riguarda la RAM, il kernel cerca di conservare i dati dei file nella RAM. Vedi per es. linuxatemyram.com ; leggi posix_fadvise (2) , fsync (2) , readahead (2) , ...

BTW, il codice Python alla fine chiamerà il codice C e utilizzerà la stessa (fornita dal kernel) syscalls ( 2) . La maggior parte dell'elaborazione relativa al file system avviene all'interno del kernel Linux . Quindi non sarà più veloce (a meno che Python non aggiunga il proprio buffer dello spazio utente ad es. leggi (2) ) dati in blocchi di megabyte, riducendo quindi il numero di syscalls eseguite).

Si noti che ogni sistema Linux è in grado di gestire molti dati del disco, con un singolo file enorme (molto più grande della RAM disponibile: si potrebbe avere un file 50Gbyte sul laptop e un file terabyte sul desktop! ) o in molti file.

    
risposta data 27.08.2014 - 09:41
fonte
1

Penso che non dipenda tanto dal linguaggio di programmazione, ma da come Linux (e altri sistemi) gestiscono i file: per ogni file creato, viene creato un inode che contiene meta informazioni sul file. Pertanto è più veloce la creazione di un file di grandi dimensioni rispetto a una miriade di quelli più piccoli.

Per quanto riguarda la RAM, il sistema operativo dovrebbe occuparsene comunque. Se troppe pagine vengono occupate, il sistema operativo le scrive sul disco rigido. Se vuoi gestirlo da solo, c'è anche una funzione di flush in python: link

    
risposta data 27.08.2014 - 09:36
fonte

Leggi altre domande sui tag

Come misurare (e migliorare) la qualità delle correzioni dei bug? [chiuso] A quale classe di algoritmi appartiene questo problema?