Newsgroup: it.comp.lang.visual-basic
Titolo: RAM e DATASET...limiti

Fino ad ora mi son sempre tenuto sotto....
adesso ho un evidente problema
Termini del problema
Parsing di un testo e relativa catalogazione parole
Prendo il mio testo...lo elaboro....trovo le occorrenze delle parole
del testo.
fin qui...
Adesso viene il bello...le parole nonsono tutte QUALITATIVAMENTE
uguali: nomi propri verbi coniugati avverbi congiunzioni parole TROPPO
comuni etc etc
Ho un DB che mi contiene una tabella "blacklist"....la interrogo...se
una parola è presente la elimino...altrimenti la catalogo
...e anche fin qui...ci siamo!
Inoltre lo schema di eliminazione è a cura mia...ogni volta che
elaboro un testo...mi dà la possibilità di scegliere, a mio giudizio,
se la parola non esiste di inserirla in blacklist o catalogarla!
Dovendo fare questo lavoro "ogni tanto" posso perdere del tempo e
interrogare il DB con
una serie di SELECT....WHERE parola='parola da controllare'
Però mi sono detto
che c***o servono i dataset e relativa datatable?
mi sono "tirato giu" la tabella blacklist ed interrogata la
datatable.....VA MOLTO PIU' VELOCE!
Solo che...leggendo e pensando...
la tabella blacklist è nulla all'inizio...ma dopo un mese
grande....dopo 6 enorme...il limite a cui tenderà sarà al massimo il
vocabolario italiano più nomi più coniugazioni di verbi
E il dataset non pagina sull'HD...o almeno che io sappia non lo fa!
Ossia il dataset una volta che il pc non ha più ram da riservargli ti
pianta un outofmemory
CAZZAROLINA
ma allora i dataset non servono a nulla....io credevo che usassero un
sistema di memoria virtuali e che se l'hd ha spazio allocassero RAM e
spazio su HD ...usassero la memoria virtuale non SOLTANTO quella
fisica!
Capite bene che su un pc da 1GB avrebbe il programma qualche
problema...su uno da 2GB o 4GB molti meno....su un vecchio pc con
512MB moltissimi!
Qualche guru mi illumini...con i dataset ci giochiamo a costruire un
interfaccia "bellina" e basta...oppure possiamo usarli anche per fare
un po di elaborazione in locale???
mah!

 CAZZAROLINA
Sei sicuro di questo?
Perchè la gestione dello swap ce l'ha l'OS non credo proprio il programma.
Il problema out of memory potrebbe essere dato da altro.

 Il problema out of memory potrebbe essere dato da altro.
Tra l'altro, se devi solo guardare se una parola esiste, non ti merita
usare una collection? Credo sicuramente sia piů veloce e snello che tenere
su un dataset.

On 9 Apr, 17:43, "Andrea [Work]" <andrea.isworkDELET...@gmail.invalid>
wrote:

fammi capire...MSDN (prendo quella in italiano)
mi dice
cito:
...L'oggetto DataSet è fondamentale per il supporto offerto da 
ADO.NET
in scenari di dati disconnessi e distribuiti. Il DataSet è una
rappresentazione di dati residente in memoria, che fornisce un modello
di programmazione relazionale coerente indipendente dall'origine
dati...."
ora io ti chiedo....UN dataset con varie datatable (non raggoingo il
numero max di rows te lo assicuro)....
UN dataset su un pc con XP pro e con 1GB di ram...quanta memoria può
occupare?
Io non lo so....ma leggo che prima o poi mi spara un OutOfMemory!!!

 su un dataset.
Yes...ma trovare la parola è una parte del problema...e già che
c'ero....alla fine mi sparava i risultati nelle tabelle del DB
e cmq il problema non si sposta...una collection quanto grande può
essere???...può occupare più posto della ram installata?
Io credo che una datatable sia più efficente....o poco si
sposta...dovrei comunque usare una hashtable...una enorme hashtable!

 Io non lo so....ma leggo che prima o poi mi spara un OutOfMemory!!!
Dai non mi far fare un ciclo finchè non pianta
l'outofmemory.....dimmelo!
eh eh :o)

 dati...."
'residente in memoria' significa residente in memoria, non in 'RAM 
fisica'.
Il sistema operativo la memoria se la gestisce lui. Che sia in Ram 
fisica o su swap, o adesso qui e poi là e poi qui e poi là di nuovo, ai 
software non interessa.
Che poi è parzialmente vero, esistono software che possono 'prendersi' 
la Ram fisica (ad esempio Sql-Server decide cosa swappare e cosa tenere 
in Ram fisica), ma non è il caso del Dataset, che si espone al sistema 
operativo per la gestione della memoria.
Quindi, l'Out of Memory è, a mio parere, un tuo fasciarti la testa 
prima di essertela rotta.
Hai ragione a preoccuparti del caso di vecchie macchine, perchè se il 
sistema si mette a swappare 2GB di roba, è chiaro che le prestazioni ne 
risentono.
In prima battuta, mi verrebbe da dirti di far eseguire il parsing e la 
relativa gestione da una Stored Procedure batch del dbms, che 
nell'accesso ai dati è talmente ottimizzato e performante da ridurti il 
tempo di elaborazione di millemila volte. Ma c'è l'intoppo 
dell'interattività che citavi...
Ciao
Alberto
-- 
Konrad Adenauer: All'intelligenza Dio ha posto limiti, alla stupidità 
no.


Non mi metto a discutere....anche perchè non ce ne è motivo....dubbio
chiarito!
Però son curioso
mi son fatto un dataset con 3 datatable uguali....per ora provo con
una tabella mi son detto
    Private Sub Button2_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles Button2.Click
        Dim n As Long
        Dim riga As Data.DataRow
        Dim tab1 As DataTable
        tab1 = DStest.Tables("TabellaTest1")
        'limite datatable 16.777.216...io sto sotto
        Me.ProgressBar1.Minimum = 0
        Me.ProgressBar1.Maximum = 16700000
        For n = 1 To 16700000
            Me.ProgressBar1.Value = n
            Try
                riga = tab1.NewRow()
                riga("idTabella1") = n
                riga("TESTO1") = "TEST1 grfyrgf rfgrufygr ufgr yugr "
                riga("TESTO2") = "TEST2 GFYTTF F TF$SAEUOIYTF  TYD R
Y FYTDST"
                riga("TESTO3") = "TEST3 56498tedft TYF YU yfF Tfy TYf
FTfttrode59877TYtyrtTtrs"
                tab1.Rows.Add(riga)
            Catch ex As Exception
                Me.TextBox1.Text = "Memoria " &
My.Computer.Info.AvailablePhysicalMemory.ToString
                Me.TextBox2.Text = n.ToString & " Memoria virtuale " &
My.Computer.Info.AvailableVirtualMemory.ToString
                Stop
            End Try
        Next
        Me.TextBox1.Text = "Memoria " &
My.Computer.Info.AvailablePhysicalMemory.ToString
        Me.TextBox2.Text = n.ToString & " Memoria virtuale " &
My.Computer.Info.AvailableVirtualMemory.ToString
        Stop
    End Sub
mmmmmmmmmmmmmmmmmmmmmm
sta girando da 10 minuti su un pc con 1gb Ram ed xpPro....sarà un
caso....ma l'unica cosa che accade....un bel warning della asus
prob....la temperatura della CPU sta salendo oltre i limiti.....
più che un crash test del NET...mi sa che è un friggiCPU questo
codice!
:oP

 wrote:> Nel suo scritto precedente, Wodka40[Google] ha sostenuto :
se interessa a qualcuno.....lanciata asus probe e task manager...e poi
il programma di test
dopo circa 20 minuti.....
asus probe ....70 gradi la cpu!!! (normalmente l'ho come ora a 49
gradi...ho 3 ventole belle grosse e pulite)
Task manager....utilizzo CPU fisso per 20 minuti su 51%
file di paging cresce cresce
...cresce....Utilizzo file di paging arrivato a 2010 e rotti Mb la
cronologia utilizzo file di paging era sull'ultima riga in alto...e il
sistema è diventato lentissimo....
per la cronaca la progress bar era a circa 1/3 del lavoro!
Quindi è vero quello che dice Albe...ma è anche vero che bisogna
trovare una formula per stabilire un limite oltre il quale non
spingersi ...per avere ancora un pc e non un trita-cpu e hard disk!
Io non so stabilirlo...ma mi premerebbe trovarla per poter dire
qualcosa del tipo "c'è bisogno di 4 GB di ram"...o..."devorimanere
sotto i 2 GB di tabelle importate per un pc con 512MB "
sgrat sgrat
Zio Bill la fa facile lui a un mega pentium superturbo a triplo
scappellamento interno e 1 TeraByte di ram...facile la vita per lui!
eh eh eh

 Y FYTDST"
Ma c'č un motivo, o č solo un test, per cui devi caricare in memoria quasi 2 
milioni di record?
-- 
Greg 

 Greg
Il test ha evidenziato che sul mio pc va in crisi a circa 1.67 miloni/
3 cioè a circa 566 mila e rotti record....(in realtà a questa cifra il
pc è inutilizzabile...quindi il limite sarà abbastanza prima!)
un così' grande tabella (basta leggere tutto il post) mi è utile per
fare dei confronti su un testo ed ammettere o meno alcune parole....
è molto più comodo avere un dizionario su un dataset....per quanto
ottimizzata sia...una query su un db è più lenta!
Il problema è che sul mio pc il limite è questo....domani provo sul
portatile con 512 di ram (e relativo file di swap diverso)....
e su Vista che succede? boh...e su un pc con un hd SATA? o su uno SCSI
(dove in teoria il file di swap/paging dovrebbe essere più veloce?)
Insomma la sensazione è che siamo comunque alla soluzione empirica...e
che se ci hanno fatto abbandonare vb6 per questa roba alla fine ci
hanno semplificato alcune cose...e complicato altre!
Insomma come si dice dalle mie parti "se non è zuppa...è pan bagnato!"
Notte notte

Ciao Wodka!
Prima domanda: vieni al Mitting il 19? Stesso posto.
Ora la mia risposta.
Per lavorare con grosse tabelle ti consiglio di usare il DataReader
perchè lavora forward-only e riga per riga.
In questo modo, pur avendo tabella enormi, in memoria hai solo la riga
che stai elaborando.
Il problema si pone se devi tornare indietro di una riga... non puoi...
devi rifare la query.
Ho creato per l'azienda in cui lavoro un motore simil-DTS (ooops... ora
si chiamano SSIS).
La gestione di tabelle grosse anche 2/3 Giga (in join tra loro... non
voglio neanche sapere quanto occupano) con sotto SQL Server 2005 su una
macchina mediamente carrozzata (2 GB di ram e un processore Xeon Dual
Core 3.0 GHz) non da problemi con il datareader.
I DataTable o, peggio, i Dataset la fanno sedere nel giro di qualche
minuto. :(
Nicola

 minuto. :(
se devi tornare indietro varie volte, pero', risparare query dubito sia il 
massimo. lo snapshot serviva, perche' piu' leggero, quando facevi un 
select=seek secco su un record, o quando aprivi un rs per confronto 
scorrendolo a senso unico.
immagino non cambi granche'.
ciao nic

 ha scritto nel messaggio
Il test ha evidenziato che sul mio pc va in crisi a circa 1.67 miloni/
3 cioè a circa 566 mila e rotti record....(in realtà a questa cifra il
pc è inutilizzabile...quindi il limite sarà abbastanza prima!)
un così' grande tabella (basta leggere tutto il post) mi è utile per
fare dei confronti su un testo ed ammettere o meno alcune parole....
è molto più comodo avere un dizionario su un dataset....per quanto
ottimizzata sia...una query su un db è più lenta!
-------
Allora mi viene da pensare che forse l'approccio non è il migliore 
possibile.
Maneggiare milioni di record su tabelle non è il masismo della vita; allora 
pensavo:
- ti crei un file di testo con tutti i record della tabella
- fai un confronto su questo per cercare l'occorrenza con le Regular 
expression
- quando l'occorrenza è ok aggirna sia il database che il file di testo
Penso che dovrebbe essere enormemente piu veloce e con una occupazione di 
ram inferiore.
greg 

 ha scritto nel messaggio

Tu dici?
la mia preoccupazione era questa....
ho 2 strade
...tengo il "dizionario" su un database...e campo tranquillo...e
ottengo la velocità proporzionale all'efficienza del DB e alla
congestione della rete e/o del pc
...oppure cerco di fare un raffronto "in memoria"...ho fatto dei
test...e.....
    Private Function AmmettiParola(ByVal miaParola As String) As
Boolean
        'qui si cassa la parola in base ad alcune regole
        Try
            If DSparole.Tables("Blacklist").Rows.Find(miaParola) Is
Nothing Then
                Return True
            Else
                Return False
            End If
        Catch ex As Exception
            Return False
        End Try
    End Function
va veloce...molto veloce!....una pagina di testo me la elabora
velocemente!
Il problema è però: dove metto il limite alla tabella blacklist?
potrei pensare....se lo sapessi....
if Limite Raggiunto THEN
     scarica tabellaBlacklist1
     spera nel GC di NET (dispose e quant'altro)
     carica tabellaBlacklist2
    ....e continua a cercare li
...e via andare....
end if
solo che LIMITERAGGIUNTO è alquanto aleatorio....dipende dal
pc...dalla ram e dal file di swap (uffa paging chiamatelo come vi
pare...ho in mente linux stamani!)
p.s.
Cercare una occorrenza in 1 2 GB di testo presumo che metta comunque
in crisi un pc con meno di 4GB di ram ...e dovendo ricorrere al file
di paging...credo convenga comunque usare un DB!
p.p.s
le soluzioni "parziali" e non di forza "bruta" sono molte...
ad esempio ...suddivido le parole trovate nel testo e le metto in una
sortedlist....
suddivido...le ricerche per lettera iniziale....
PIPPO
PLUTO
POLDO
caricheranno una datatable "BlacklistP"....e cerco....la scarico....
TAP
TIP
TOPOLINO
caricheranno una datatable "BlacklistT"....e cerco....la scarico.... e
così via
logicamente il DB remoto rimane unico e la datatable vive con una
SELECT
soluzione elaborata...si allontana il limite di non ritorno....
però
come sempre....
ti tocca lavorare di workaround e non di forza bruta!
e francamente un po di fatica sti cazzo di pc dovrebbero farla pure
loro!
Va che "pensata"...per cercare una serie di dati in una tabella
"grande"
Evabbe.....c'è poco da fare!

 di paging...credo convenga comunque usare un DB!
Vodka, rispondo solo a questo e insisto e ripeto: prova a vedere come 
funzionano e quanto son veloci queste Regular Expressions.
Io non ho mai avuto bisogno di usarle, ma sto leggendo (per meglio dire: 
godendo) un libro di Balena (i trucchi di VB6) e sembrerebbe che le funzioni 
di questa libreria come logica e tempi di risposta siano piu vicini a una 
query su google piuttosto che su un classico database . Che ti costa 
provare?
-- 
Greg 

 funzionano e quanto son veloci queste Regular Expressions.
Greg, le regex sono quanto di più lento ci possa essere.
Sono potentissime, nel senso che ti danno grande controllo sui pattern 
di ricerca, ma hanno il difetto di essere estremamente lente.
Nicola

 ha scritto nel messaggio 
news:47ff27f4$0$29978$5fc...@news.tiscali.it...

Grazie delle info; non lo sapevo, non avendole mai provate.
Accantonate le regex, rileggo meglio il primo post di wdoka
Greg