La chiamata di sistema stat() è davvero costosa? Ho letto da qualche parte che è una chiamata di sistema costosa da usare. É davvero? Se è così ci sono altre alternative?Stat() è una chiamata di sistema costosa?
In un'impostazione tipica, stat(2), fstat(2) e lstat(2) sono le uniche tecniche sane per ottenere informazioni sui file. Se si riscontrano problemi di prestazioni, sarebbe utile profilare la propria applicazione e vedere cosa succede.
Per il profilo, compilare con gcc -pg ed eseguire l'eseguibile con gprof(1).
Potresti, potenzialmente, passare a utilizzare una libreria più grande come Qt, ma probabilmente non gestirà alcun problema di prestazioni, e probabilmente useranno comunque stat(2).
Quindi, se è costoso o no, non ci sono alternative ragionevoli.
Detto questo, come nel commento di Jim Mcnamara, non è costoso proprio per questi motivi. Dato che non ci sono alternative, i programmatori di glibc e linux lo hanno reso il più performante possibile.
Inoltre, considera di essere molto attento ai risultati del profilo eseguiti più volte. Avrai memorizzato nella cache ogni file che hai toccato, quindi la seconda esecuzione apparirà più o meno falsamente più velocemente sullo stesso set di file quando esegui nuovamente la ricerca. –
Un po 'come un intervento a cuore aperto a seguito di un attacco di cuore ... sì, è costoso, ma qual è l'alternativa ...? – Jonathan
E il team di chirurgia è un team di programmatori C incredibilmente talentuoso da tutto il mondo? –
La domanda sorge come "V/s costoso richiesto".
Ogni processo su Unix viene eseguito in due modalità: "Spazio utente" e "Spazio Kernel" e quando vengono emesse chiamate di sistema come open(), write(), stat(), il processo passa da User Space a Modalità Kernel che è costosa, ma solo se non stiamo facendo nulla di significativo con questa chiamata di sistema. Come se stessimo usando stat() per stampare solo l'ultima ora di accesso del file e nulla di più che stiamo facendo, allora probabilmente dovrei evitare .
Quindi, in primo luogo, ci dovrebbe essere una buona ragione per chiamare stat(). In secondo luogo se si desidera confrontare i tempi di esecuzione relativi di diversi pezzi del codice, utilizzare uno strumento di profilazione, che fornirà le statistiche esatte per dimostrare quale chiamata di funzione è costosa e quale no.
In quale altro modo si propone di fare ciò che fa? Evitare stat non ha senso. Se hai fatto un ls nella directory in qualsiasi momento, in passato probabilmente i file sono già memorizzati nella cache. Ad ogni modo - quindi, in che altro modo prendi mtime? Altro che chiamare stat o usare ls che chiama stat. –
È sempre possibile utilizzare strace nell'eseguibile. Non è necessario ricompilare. Questa funzione consente di ottenere il tempo di esecuzione effettivo per ogni chiamata di sistema.
'costoso()'? È un'altra chiamata di sistema? – devnull
Hai provato la creazione di profili per vedere qual è effettivamente il costo? – ssube
La risposta breve è no. L'unica parte costosa sta leggendo l'inode del file dal disco. Dato che Linux inode in modo molto efficace, praticamente qualsiasi file che è stato visto in qualsiasi modo dal momento dell'avvio avrà già avuto l'inode già salvato nella cache. Ci sono altre chiamate come access(), ma chiama stat() comunque. fopen() o semplicemente open utilizza più risorse. –