VARIAVEIS DO PROJETO
Pessoal...
Là sobre o Garbage Collector, và opiniões diversificadas sobre ele...gostaria de ouvir vocês...experientes e iniciantes na plataforma .NET
Tenho costume de referênciar objetos e criar variáveis...mas nem sempre as esvazio:
vale o mesmo para os objetos OleDB e outros...
é necessário esvaziar o objeto ? ou podemos esperar e confiar no Garbage Collector ?
Là sobre o Garbage Collector, và opiniões diversificadas sobre ele...gostaria de ouvir vocês...experientes e iniciantes na plataforma .NET
Tenho costume de referênciar objetos e criar variáveis...mas nem sempre as esvazio:
Dim sTexto as String = [Ô]Nomenomenomeome...[Ô]
sTexto = String.Empty [ô] por exemplo...
vale o mesmo para os objetos OleDB e outros...
é necessário esvaziar o objeto ? ou podemos esperar e confiar no Garbage Collector ?
particularmente é um descuido q tenho, sempre cai nakela questao, vou usar o q esta nessa variavel ali mais na frente e la fica até o fim do programa
O GC do .Net é muito bem-resolvido.
Se comparado ao primo VS98 então, é como comparar um Volvo VT880 com um triciclo Bandeirantes 1950!
O problema é outro, não são variáveis em sÃ, mas os ponteiros de conexões e de outros processos.
Por exemplo, é comum ver códigos onde um arquivo é aberto, carregado para stream e devolvido por uma função, mas nunca mais é fechado. Da mesma forma, e mais frequente ainda, pois se encontram [Ô]exemplos[Ô] e [Ô]modelos[Ô] ás centenas, inclusive oriundos da Microsoft, onde a conexão á uma fonte de dados é aberta mas nunca mais encerrada.
[Ô]!Ah, mas a ADO.Net encerra suas conexões sozinha...[Ô] - Verdade. Mas quando? Há um tempo, e há um cache, sempre.
E tem mais: A GC se encarrega de grande parte do problema, sem dar nem sinal de que fêz algo, e em outros casos, como os acima, demora o tempo necessário para que o processo [Ô]pendurado[Ô] pelo programador descuidado se encerre ou cause um time-out, mas isso não é válido para processos paralelos ao aplicativo, como aqueles lançados pelo aplicativo á DLLs e outros Exes.
Assim, não é, na minha opinião, a GC do VS quem tem o dedo-sujo nessa ficha de inquérito, mas sim a memória paraguaya que os programadores espetam no cérebro para reduzir custos...
E só para garantir, a minha é coreana, 256K SDR, marca KingTong, N.F. 08550/1966-B há muuuitos anos (se não me falha a memória)...
Se comparado ao primo VS98 então, é como comparar um Volvo VT880 com um triciclo Bandeirantes 1950!
O problema é outro, não são variáveis em sÃ, mas os ponteiros de conexões e de outros processos.
Por exemplo, é comum ver códigos onde um arquivo é aberto, carregado para stream e devolvido por uma função, mas nunca mais é fechado. Da mesma forma, e mais frequente ainda, pois se encontram [Ô]exemplos[Ô] e [Ô]modelos[Ô] ás centenas, inclusive oriundos da Microsoft, onde a conexão á uma fonte de dados é aberta mas nunca mais encerrada.
[Ô]!Ah, mas a ADO.Net encerra suas conexões sozinha...[Ô] - Verdade. Mas quando? Há um tempo, e há um cache, sempre.
E tem mais: A GC se encarrega de grande parte do problema, sem dar nem sinal de que fêz algo, e em outros casos, como os acima, demora o tempo necessário para que o processo [Ô]pendurado[Ô] pelo programador descuidado se encerre ou cause um time-out, mas isso não é válido para processos paralelos ao aplicativo, como aqueles lançados pelo aplicativo á DLLs e outros Exes.
Assim, não é, na minha opinião, a GC do VS quem tem o dedo-sujo nessa ficha de inquérito, mas sim a memória paraguaya que os programadores espetam no cérebro para reduzir custos...
E só para garantir, a minha é coreana, 256K SDR, marca KingTong, N.F. 08550/1966-B há muuuitos anos (se não me falha a memória)...
O gc se encarrega de limpar a memoria dos [ô]lixos[ô].
mas quando vc for usar classes sempre de um dispose ou senao use um [ô]using[ô] pra quando tiver terminado de [ô]usar[ô] ele é dispensado automaticamente da memoria.
mas quando vc for usar classes sempre de um dispose ou senao use um [ô]using[ô] pra quando tiver terminado de [ô]usar[ô] ele é dispensado automaticamente da memoria.
PHOENIX...
explica melhor esse Using...pois nunca o usei
explica melhor esse Using...pois nunca o usei
em C#:
using (SqlDataReader dr = cmd.ExecuteReader())
{
//Faz o que quiser com o dataReader
}
em VB.NET:
Using dr As SqlDataReader = cmd.ExecuteReader()
[ô]Faz o que quiser com o dataReader
End Using
O porém é que o bloco using, só pode ser usado com classes que implementam a interface IDisposable. Uma maneira simples de saber se a classe implementa o IDisposable, é ver se ela tem o método Dispose(), se tiver, pode usar o bloco using nela. Com o bloco using, ao ser fechado, ele automaticamente [Ô]apaga[Ô] a variável.
using (SqlDataReader dr = cmd.ExecuteReader())
{
//Faz o que quiser com o dataReader
}
em VB.NET:
Using dr As SqlDataReader = cmd.ExecuteReader()
[ô]Faz o que quiser com o dataReader
End Using
O porém é que o bloco using, só pode ser usado com classes que implementam a interface IDisposable. Uma maneira simples de saber se a classe implementa o IDisposable, é ver se ela tem o método Dispose(), se tiver, pode usar o bloco using nela. Com o bloco using, ao ser fechado, ele automaticamente [Ô]apaga[Ô] a variável.
KERPLUNK, me surgiu uma dúvida agora...
Se eu efetuar um [txt-color=#0000f0]return[/txt-color] dentro do bloco do using, ele automaticamente reconhece que eu sai do bloco e executa o método Dispose?
Se eu efetuar um [txt-color=#0000f0]return[/txt-color] dentro do bloco do using, ele automaticamente reconhece que eu sai do bloco e executa o método Dispose?
using (SqlDataReader dr = cmd.ExecuteReader())
{
return Nothing
}Ao encontrar o final do bloco, quando você cria um bloco Using, o GC se encarrega de [Ô]esvaziar[Ô] o processo e dispensar a instância, sim.
O que é mais interessante com o uso desse bloco, é que, ao contrario dos demais, ele consegue lidar inclusive com as instâncias COM e ActiveX. O que está dentro desse bloco NÃO é encerrado no exato momento em que o bloco termina mas o ponteiro do processo passa á ser tratado pelo GC, ou seja, quando o processo encerrar, o GC vai cumprir seu trabalho.
é importante, no entanto, que não se faça um retorno de função DENTRO do bloco Using, permitindo com isso que o GC reconheça o final do bloco. No exemplo dado acima, em VB, ficaria parecido com:
Dim ret As Object = Nothing
Using dr As SqlDataReader = cmd.ExecuteReader()
ret = Nothing
End Using
Return ret
é exatamente que o KERPLUNK falou ^^
Using comando as new sqlcommand([Ô]Insert into . . . [Ô],Conexao)
[ô]codigos . . .
End Using [ô]<- Usado apenas em classe que possui o [ô]idisposable[ô] ...
Sempre bom utilizar o using pra classes que permitem,pois nem sempre lembramos do [Ô]classe.dispose[Ô] acaba acumulando um lixo na memoria,agora,com variavel nao precisamos nos preocupar,assim que acaba um evento aquela variavel [ô]morre[ô] o tempo de vida util acaba,mesma coisa com instancias de classes feitas dentro de uma procedure,function.
Na programação antiga,o public era problema,hoje em dia tem o gc,clr gerencia o codigo,mas nao é aconselhavel criar variavel e fica largando ela sem utilizar,fiz o teste e realmente a performance do programa cai um pouco,consome memoria sim,obvio a variavel é um espaço alocado! 4 bytes aqui e ali,ja viu!..
Using comando as new sqlcommand([Ô]Insert into . . . [Ô],Conexao)
[ô]codigos . . .
End Using [ô]<- Usado apenas em classe que possui o [ô]idisposable[ô] ...
Sempre bom utilizar o using pra classes que permitem,pois nem sempre lembramos do [Ô]classe.dispose[Ô] acaba acumulando um lixo na memoria,agora,com variavel nao precisamos nos preocupar,assim que acaba um evento aquela variavel [ô]morre[ô] o tempo de vida util acaba,mesma coisa com instancias de classes feitas dentro de uma procedure,function.
Na programação antiga,o public era problema,hoje em dia tem o gc,clr gerencia o codigo,mas nao é aconselhavel criar variavel e fica largando ela sem utilizar,fiz o teste e realmente a performance do programa cai um pouco,consome memoria sim,obvio a variavel é um espaço alocado! 4 bytes aqui e ali,ja viu!..
Citação::
Ao encontrar o final do bloco, quando você cria um bloco Using, o GC se encarrega de [Ô]esvaziar[Ô] o processo e dispensar a instância, sim.
O que é mais interessante com o uso desse bloco, é que, ao contrario dos demais, ele consegue lidar inclusive com as instâncias COM e ActiveX. O que está dentro desse bloco NÃO é encerrado no exato momento em que o bloco termina mas o ponteiro do processo passa á ser tratado pelo GC, ou seja, quando o processo encerrar, o GC vai cumprir seu trabalho.
é importante, no entanto, que não se faça um retorno de função DENTRO do bloco Using, permitindo com isso que o GC reconheça o final do bloco. No exemplo dado acima, em VB, ficaria parecido com:Dim ret As Object = Nothing
Using dr As SqlDataReader = cmd.ExecuteReader()
ret = Nothing
End Using
Return ret
Boa resposta!
Eu já utilizo dessa maneira. Foi justamente por isso que questionei se o Return dentro do bloco Using disparava o método Dispose.
E bem vindo de volta PROFESSOR, por mais que não tenhamos nos conhecidos nos tempos em que você frequentava o fórum, já ouvi muito de você.
Beleza galera !
Entendà tudo que falaram...só mais um pequeno detalhe de minha dúvida:
se em minha [Ô]Private Sub[Ô] eu chamo um DataSet, DataAdapter e OleDbConnection e Command e uso o [Ô]Using[Ô] para desalocar a memoria, e no final dessa [Ô]Private[Ô] tem uma variável Booleana que define se vai executar o processo seguinte ou não...digamos que [Ô]sim[Ô], e novamente na [Ô]Sub[Ô] seguinte seja preciso abrir novamente um DataSet e demais objetos, quero saber se tem problema em ficar alocando e desalocando memorias assim...
Outra dúvida, é nos casos de variáveis [Ô]sem[Ô] o [Ô]Dispose[Ô], como Strings, Integers, Doubles e etc... é preciso mesmo fazer um:
Deu pra entender né galera ?!
Entendà tudo que falaram...só mais um pequeno detalhe de minha dúvida:
se em minha [Ô]Private Sub[Ô] eu chamo um DataSet, DataAdapter e OleDbConnection e Command e uso o [Ô]Using[Ô] para desalocar a memoria, e no final dessa [Ô]Private[Ô] tem uma variável Booleana que define se vai executar o processo seguinte ou não...digamos que [Ô]sim[Ô], e novamente na [Ô]Sub[Ô] seguinte seja preciso abrir novamente um DataSet e demais objetos, quero saber se tem problema em ficar alocando e desalocando memorias assim...
Outra dúvida, é nos casos de variáveis [Ô]sem[Ô] o [Ô]Dispose[Ô], como Strings, Integers, Doubles e etc... é preciso mesmo fazer um:
Dim stexto As String = [Ô]Meu texto...[Ô]
script.......
stexto = String.Empty
Deu pra entender né galera ?!
Tópico encerrado , respostas não são mais permitidas