[VB.NET] Velocizzare lettura di più file

[Pirelli72]

Inoltre cercando di capire quale fosse la differenza tra le funzioni:

 My.Computer.FileSystem.GetFiles

,

System.IO.Directory.GetFiles

,

 Dim info() As FileInfo = dir_info.GetFiles

e spulciando tra le classe del Framework mi pare di capire, forse era ovvio, fanno capo tutte alla stessa funzione....

Private Shared Function InternalGetFiles(ByVal path As String, ByVal searchPattern As String, ByVal searchOption As SearchOption) As String()
    Return Directory.InternalGetFileDirectoryNames(path, path, searchPattern, True, False, searchOption)
End Function

di cui

Friend Shared Function InternalGetFileDirectoryNames(ByVal path As String, ByVal userPathOriginal As String, ByVal searchPattern As String, ByVal includeFiles As Boolean, ByVal includeDirs As Boolean, ByVal searchOption As SearchOption) As String()
    Dim list As New List(Of String)(FileSystemEnumerableFactory.CreateFileNameIterator(path, userPathOriginal, searchPattern, includeFiles, includeDirs, searchOption))
    Return list.ToArray
End Function

di cui

<SecuritySafeCritical> _
Friend Shared Function CreateFileNameIterator(ByVal path As String, ByVal originalUserPath As String, ByVal searchPattern As String, ByVal includeFiles As Boolean, ByVal includeDirs As Boolean, ByVal searchOption As SearchOption) As IEnumerable(Of String)
    Return New FileSystemEnumerableIterator(Of String)(path, originalUserPath, searchPattern, searchOption, New StringResultHandler(includeFiles, includeDirs))
End Function

infine, utilizzanso le API

<DllImport("kernel32.dll", CharSet:=CharSet.Auto, SetLastError:=True)> _
Friend Shared Function FindFirstFile(ByVal fileName As String, <[In], Out> ByVal data As WIN32_FIND_DATA) As SafeFindHandle
End Function

e

<DllImport("kernel32.dll", CharSet:=CharSet.Auto, SetLastError:=True)> _
Friend Shared Function FindNextFile(ByVal hndFindFile As SafeFindHandle, <[In], Out, MarshalAs(UnmanagedType.LPStruct)> ByVal lpFindFileData As WIN32_FIND_DATA) As Boolean
End Function

Buona lettura

[andreaciao_22]

mi è venuto in mente una cosa...
visto che si sviluppa in vb.net 2008, e per migliorarne ulteriormente la velocità, perchè non usare Linq per farsi restituire tutti i txt?

[alka]

Originariamente inviato da andreaciao_22
visto che si sviluppa in vb.net 2008, e per migliorarne ulteriormente la velocità, perchè non usare Linq per farsi restituire tutti i txt?

LINQ è un "sottolinguaggio" per creare espressioni di interrogazione sugli oggetti, ma l'espressione viene sempre ricondotta all'uso di metodi che alla fine espletano l'interrogazione richiesta.

Non vedo quindi come potrebbe essere utile in questo frangente.

[eziogsv]

Riguardo al servizio .Net Optimizer... è disabilitato da sempre

Riguardo ai problemi Hw... ho scaricato 4 programmi di benckmark di HD e tutti mi danno tempi in lettura NON inferiori a 60 MB/sec con punte di 100 MB/s.

L' antivirus non controlla e quindi non rallenta i files .txt.

E' vero che il mio E6600 non è nuovissimo, ma ho 3Gb di eccellenti Corsair CMX2.

Pulisco e deframmento regolarmente, XP SP3 si apre in pochi secondi, i programmi girano bene... qui c' è qualcosa che mi sfugge.

Pirelli hai scansionato 25GB in pochi secondi, ma io le sole scansioni le faccio in meno di 1 secondo: i miei test dimostrano che il 99.99% del tempo se lo mangia la riga di codice:

sContentFile = sr.ReadToEnd

occorre pertanto vedere per quante volte hai dovuto allocare memoria per ogni nuova lettura della stessa variabile sContentFile, cioè quanti file di testo hai trovato.

Comunque ho provato il tuo listato, il risultato è questo: 984: 00:00:40.2070493... il peggiore di tutti. Anche le letture successive impiega mediamente 200 millisecondi circa di più della mia routine.

Ho letto sul web cento cose diverse a riguardo della specifica lettura dei dati (più veloce questo, più veloce quello, meglio dimensionare tali buffer, meglio leggere array di char, di byte, fare encoding...) provato di tutto un pò, siamo sempre sui 33 secondi e più al primo passaggio e sul mezzo secondo nei successivi.

D' altronde a meno che i programmatori MS non siano impazziti i diversi codici .Net alla fin fine per fare quel determinato lavoro finale come giustamente fa notare Alka creeranno più o meno lo stesso assembler.

.

[eziogsv]

Materiale per meditare...

dunque, come detto se dal mio codice tolgo la riga

FileReader = sr.ReadToEnd

al primo avvio mi occorrono circa 3 secondi, quindi per cercare i 984 files, leggerne i titoli, aprirli e chiuderli sono 3 secondi di tempo.

Adesso ho creato un unico enorme file di testo da 48 MB per vedere al primo lancio del programma in quanto tempo lo leggo col codice di cui sopra: 3010 ms, cioè siamo sui 3 secondi!!

Ora, se per leggere i titoli, aprire e chiudere 984 files mi occorrono 3 secondi e leggere 48 MB di dati altri 3 secondi, la domanda è: perché per aprire e leggere anche i dati dei 984 files occorrono 33 secondi e non 3+3=6????

Ok, la testina dovrà fare qualche spostamento in più, si dovranno aprire 1000 piccoli buffer anziché uno enorme.... ma 27 secondi di differenza (LEGGESI VENTISETTE SECONDI!!) per la bisogna sono una enormità, roba da PentiumII, non da E6600!!! Dove è l' inghippo??

In realtà, lo confesso, speravo che una volta preparato l' enorme buffer leggendo il singolo file grosso... leggendo poi i 1000 files la cosa venisse considerata un pò come una seconda lettura velocizzando la cosa: pensiero completamente errato, dopo la prima mega lettura per leggere successivamente sempre in prima lettura i 1.000 files mi servono 37 secondi, 4 più della media.
.

[alka]

Ripeto: per me non è un problema legato al codice - anche se a questo punto lo posterei integralmente, includendo le parti che potrebbero sembrare superflue - quindi verificherei con un profiler, o ripeterei il test su un'altra macchina, o comunque indagherei su ciò che avviene a basso livello nel programma nel corso dell'operazione.

Non è una questione di ottimizzazione: ho utilizzato centinaia di volte le stesse classi, allo stesso modo, e non ho mai avuto un simile problema.

Ciao!

[Pirelli72]

Non ci hai ancora detto a cosa serve tale elaborazione, quando viene/deve essere avviata.

[alpynet]

Originariamente inviato da eziogsv
.... ma 27 secondi di differenza (LEGGESI VENTISETTE SECONDI!!) per la bisogna sono una enormità, roba da PentiumII, non da E6600!!! Dove è l' inghippo??

Ciao, hai provato il programma in un'altro pc per vedere se ottieni i stessi tempi?

Probabilmente, come evidenziato da alka, il problema è il tuo pc, visto che facendo delle prove (~2000 file, ~100MB) nel mio pc (quad core Q9550, ram 3GB) impiego meno di un secondo.