Newsgroup: it.comp.lang.visual-basic
Titolo: [?] Classi di dati e velocità di distruzione

Salve a tutti,
sono nuovo del gruppo, ho dato una scorsa agli articoli, ma non ho
trovato niente di inerente al mio problema...
ho creato diverse classi VB5 dipendenti fra loro. Orientativamente, ogni
classe contiene una collection di istanze della classe di livello
inferiore. Il tutto è strutturato con una forma Object oriented pura e
da manuale. Il layout delle classi è complesso, cerco di sintetizzare:
Classe "Bulk" - 1 sola istanza, collection di  100 Patches
    Classe "Patch" - 100 istanze, collection di 12 Effects
            Classe "Effect" - 12 istanze, ognuna con una media di 20
Parameters
                    Classe "Parameter" - media di 20 istanze, ognuna di
5 Long Integer
Bene (!) Ogni classe ha una routine Initialize che ne imposta le
collection, in modo da riempirle fin da subito con le istanze degli
oggetti di livello inferiore (che sono in numero e hanno caratteristiche
ben definite).
*Quello che mi stupisce* è che la velocità di distruzione di un Bulk
intero, è superiore del doppio rispetto alla velocità di creazione di
tutto l'oggetto Bulk, strutturato come sopra.
Naturalmente, ho fatto verifiche: NON ci sono routine Class_Terminate in
alcuna delle classi di livello inferiore che potrebbero generare
chiamate a ripetizione durante la distruzione delle classi di livello
più basso...
Praticamente, la sola rimozione dalla memoria di 1,5 megabyte di dati
richiede circa 20 secondi su un PentiumII 233 64MB. 20 secondi!!!
Quindi, se il manuale di VB afferma che organizzando la gestione dei
dati per classi personalizzate di insiemi tutto si semplifica (!), non
tiene conto del fatto che per grandi moli di dati (Se una serie di 100
collections di 1000 dati è una grande mole di dati) si perde più tempo
macchina in organizzazione interna delle classi che in lavoro
effettivo...
Non c'è traccia di informazioni sul MSDN Library che ho (non
aggiornato...)
Qualcuno ne sa qualcosa? E' terribile!! Grazie!
Flavio Ronco
f.ronco@*NonMiServeNiente*
flashnet.it
http:\\
www.geocities.com
\Paris\3461\
-------------------------------------------------------------
"Dio ha uno screensaver. Speriamo che non tocchi il mouse..."


Cosa ti devo dire?
Purtroppo funziona cosi'... prendere o lasciare.
Se proprio non sei costretto da qualcuno (come me :-( ad usare VB, ti
consiglierei di usare qualche altro ambiente di sviluppo... (Delphi? :-)
Altra soluzione: lascia perdere l'object oriented (che in VB fa
letteralmente schifo) e usa degli array di UDT (User Defined Type =
strutture), potrebbe essere piu' veloce.
--
Roal Zanazzi
z...@iol.it


Il guaio sta nel fatto che una modifica in un UDT non genera eventi (ho bisogno
di intercettare le modifiche  generate sia da un centinaio di controlli (si
tratta di un'applicazione di pilotaggio di un'apparecchiatura MIDI con centinaia
di parametri) in più punti nel programma: mooolto più semplice e funzionale
disporre dell'evento Change direttamente sui dati ...
Comunque ci penserò. E' già molto che il fenomeno di cui parlavamo non sia
dovuto a errori di strutturazione degli oggetti. Se succede anche ad altri non
mi tranquillizzo, ma mi do una spiegazione, perlomeno!



Ho praticamente lo stesso problema, consolati perň:
per la distruzione della struttura di classi che ho io ci impiega molto di
piů
(5 min su un PII 350 con 128Mb e WIN NT Workstation)
Ho cercato di risolvere il problema in vari modi ma risultati nessuno.
Le classi nelle Collection sono *VARIANT* con ben 16 Byte di descrizione,
e questo č il primo problema.
Io ho collezioni che contengono Membri di tipo String, da quanto sono
riuscito
a trovare sui vari NG e sui vari manuali la Garbage Collection di VB ha
parecchi
problemi a disallocare le stringhe e parecchi problemi a disallocare le
collection
per cui io sono sfigato al *QUADRATO*.
Ho quasi deciso di riscrivere tutto in C++ dalla disperazione, in VB per 2
Min di
elaborazione effettiva dei dati se ne perdono 5 per la distruzione della
stuttura.
Lo so ... Non ti ho dato una soluzione ma .... Mal comune ...
Se trovi un modo decente per risolvere il problema postami, farň altrettanto
nel caso fossi io a trovare la soluzione.
Ciao Salvatore


