Newsgroup: it.comp.appl.access
Titolo: Che configurazione per fare girare veloce un programma in Access?

Capisco che non esista UNA configurazione ideale ma ci sono diverse 
configurazioni in base a qual'e' il compito da svolgere
Ma tanto per non restare nel generico, queste routine
 
https://github.com/timabell/msaccess-vcs-integration/blob/master/MSAccess-VCS/VCS_ImportExport.bas
 
(in particolare la ExportAllSource)
 
ci mette circa 8 minuti per essere completata, sul mio pc di lavoro
Stiamo parlando di un i5, quad core, di cui uno solo sembra essere 
impegnato a far qualcosa mentre gli altri 3 stanno a girarsi i pollici
Access 2013, versione 32 bit
Disco ssd con qualche punto percentuale di occupazione
Ram 8 Gbyte impegnata, altri 8 di ram libera e disponibile
La domanda e: supponiamo desideri adottare un hardware che sia in grado 
di velocizzare la procedura sopra (che sembra usare cpu e disco) su cosa 
mi converrebbe puntare?
Perche' gia' ora vedo solo un core impegnato al posto di tutti e quattro?
 


Access non è in grado di gestire più di un processore per volta:
 
 
https://www.experts-exchange.com/questions/27547834/MS-Access-2010-on-8-CPU-server-how-to-optimize.html
 
 
 
https://social.msdn.microsoft.com/Forums/office/en-US/3a33ce80-b93e-4429-be0a-b56404d458f5/percentage-of-cpu-assigned-to-ms-access-2010?forum=accessdev
 
 
 
Le prestazioni delle singole sessioni di Access sono invece influenzate dal cloccaggio delle CPU (quindi meglio un PC con pochi processori ad alto clock).
 
Potrebbero influire anche i servizi di Windows in memoria: in modalità provvisoria le prestazioni migliorano?
Potresti provare a disabilitare servizi non essenziali:
 
https://www.navigaweb.net/2008/10/velocizzare-il-pc-windows-disabilitando.html
 
 
Comunque se utilizzi SQL Server enterprise, fatto lavorare il più possibile lato server, le cose cambiano dato che è in grado di sfruttar bene hardware multicore.
 
Saluti estivi
 
 
 
 
 
 
 
 

Access 2013, versione 32 bit
 
Se non sbaglio a leggere, questa zona di codice è MICIDIALE per qualunque 
elaboratore:
 
For Each obj_type In Split( _
       "forms|Forms|" & acForm & "," & _
       "reports|Reports|" & acReport & "," & _
       "macros|Scripts|" & acMacro & "," & _
       "modules|Modules|" & acModule _
       , "," _
   )
 
[...]
                       For Each doc In 
Db.Containers(obj_type_name).Documents
[...]
 
In pratica sono due cicli innestati, deduco che la complessita 
computazionale si aggiri su O(n^2).
E non ho visto se ci sono altri loop nelle subroutine o funzioni.
Il problema non è tanto la potenza di calcolo, quanto l'algoritmo che 
inchioda la velocità alla complessità quadratica.
Puoi aumentare la potenza di calcolo quanto vuoi, ma noterai sempre un 
rallentamento.
Da quello che mi pare di intuire, le routine esportano tutti gli oggetti di 
un applicativo Access: credo siano routine prese dalla rete che si applicano 
in generale, ma non sarebbe il caso di semplificarle? Si potrebbe fare tutto 
con 20 istruzioni in sequenza, senza loop (poi magari mi sbaglio). 
 


In che senso in sequenza?
Se fai un ciclo per tutte le form, e poi un ciclo per tutti i report, e 
poi un ciclo per tutti i moduli, e poi un cicolo per tutte le macro, e' 
la stessa cosa che fare i due cicli annidati, con quello esterno che 
gira tra form, report, moduli, macro
Ma probabilmente non ho capito bene cosa vuoi dire
Cosa intendevi esattamente?
Giusto per inquadrare quello che intendo con 'lento' , ci mette circa 8 
minuti per esportare circa 1700 oggetti, una media di 3,5 oggetti/sec
Il che mi pare tantino, ad eccezione di alcuni oggetti che sono 
particolarmente corposi, ma la media e' dai pochi byte alle poche decine 
di Kbyte, per questo mi aspetterei una rapidita' maggiore

minuti per esportare circa 1700 oggetti, una media di 3,5 oggetti/sec
 
Io proverei a misurare i tempi di ciascuna istruzione tramite una sessione 
di Debug, e da qui capirei quali istruzioni sostituire oppure quali parti di 
sorgente riorganizzare.
Comunque è un codice esteso e non ho tempo per provarlo, quindi ammetto la 
mia svogliatezza nel continuare l'analisi e passo la palla agli esperti :-)