Consumo de memória
[color=red:7c0592fdf2]Título editado por Massuda
Por favor, procure usar um título descritivo.
No caso de reincidência, seus tópicos poderão vir a ser bloqueados.
Leia as :arrow: [url=http://forum.clubedelphi.net/viewtopic.php?t=6689]Regras de Conduta[/url] do fórum, em especial o item 1.e.[/color:7c0592fdf2]
Dúvida 1--Pessoal um programador experiente me falou algo que fiquei com dúvida, é verdade que declarar um campo de uma tabela desta forma
IbdtsPagamentosCODIGO.asinteger
Usa mais memória e processamente que declarar assim
IbdtsPagamentos.fieldbyname(´CODIGO´).asinteger
????Qual a forma mais prática e otimizada de usar????
Dúvida 2
Qual a forma de identação digamos ´homologada´ pela Borland ???
Desta forma :
if ... then begin
end else begin
end;
ou assim
if ...then
begin
end else
begin
end;
São dúvidas bobas, mas o cara me enche o saco por causa disso...desde já agradeço
Estanieski
Curtidas 0
Respostas
Massuda
12/03/2008
No futuro, evite criar um tópico contendo dúvidas sem relação entre elas.
GOSTEI 0
Pedroso
12/03/2008
Bom .... vamos por partes.
1º
IbdtsPagamentosCODIGO.asinteger (Quem é o campo aqui ? Pagamentos ou codigo ? Ou Codigo de pagamentos?)
IbdtsPagamentos.fieldbyname(´CODIGO´).asinteger (Aqui eu sei quem é o campo.)
2º
if ... then begin
end else begin
end;
Tu acha melhor usar assim ?
if ... then
begin
end else
begin
end;
Pela amor de Deus ... me diz que não.....
3º
Dúvidas nunca são bobas (dependendo do abobado) e sempre bom perguntar.
Mas da proxima vez pergunta pro teu chefe ....... tu num grupo, este grupo tem um chefe, e é ele quem sabe como deve ser feito.
Ass.
Cara que te enche o saco.
1º
IbdtsPagamentosCODIGO.asinteger (Quem é o campo aqui ? Pagamentos ou codigo ? Ou Codigo de pagamentos?)
IbdtsPagamentos.fieldbyname(´CODIGO´).asinteger (Aqui eu sei quem é o campo.)
2º
if ... then begin
end else begin
end;
Tu acha melhor usar assim ?
if ... then
begin
end else
begin
end;
Pela amor de Deus ... me diz que não.....
3º
Dúvidas nunca são bobas (dependendo do abobado) e sempre bom perguntar.
Mas da proxima vez pergunta pro teu chefe ....... tu num grupo, este grupo tem um chefe, e é ele quem sabe como deve ser feito.
Ass.
Cara que te enche o saco.
GOSTEI 0
Emerson Nascimento
12/03/2008
1o.
se você já possui os campos persistidos (motivo pelo qual pode usar IbdtsPagamentosCODIGO.asinteger), não faz diferença usar IbdtsPagamentosCODIGO.asinteger ou IbdtsPagamentos.fieldbyname(´CODIGO´).asinteger, visto que a memória já está alocada. o que você perceberá é que se você usar IbdtsPagamentosCODIGO.asinteger o retorno da informação será mais rápido porque o conteúdo já estará alocado na memória, enquanto que, com o uso de IbdtsPagamentos.fieldbyname(´CODIGO´).asinteger o dataset irá fazer uma varredura na lista de campos até encontrar o campo informado - ´CODIGO´ - e só então irá retornar seu valor.
se você NÃO persistir os campos, com certeza alocará menos memória e terá de usar somente o esquema IbdtsPagamentos.fieldbyname(´XXX´).asXXX.
2o.
no caso de apenas uma linha de comando:
no caso de mais de uma linha:
explico:
se sua condição tem apenas uma linha de resposta, como você faz?
ou
???
eu uso a primeira forma, então, pra mim, somente o comando em si (if..then ou else) deve estar na linha, visto que [i:e64f0204e0]begin...end[/i:e64f0204e0] são utilizados para conjuntos de comandos. eu vejo isso nas funções e procedimentos do Delphi.
[i:e64f0204e0]procedure TForm1.Button1Click(Sender: TObject);
begin
end;[/i:e64f0204e0]
e não
[i:e64f0204e0]procedure TForm1.Button1Click(Sender: TObject); begin
end;[/i:e64f0204e0]
em todos os exemplos mostrados na ajuda do Delphi o [i:e64f0204e0]begin[/i:e64f0204e0] está sempre na linha seguinte, e é esse o padrão que eu uso.
agora, se você trabalha com uma equipe, o bom mesmo é seguir o padrão adotado pela equipe.
se você já possui os campos persistidos (motivo pelo qual pode usar IbdtsPagamentosCODIGO.asinteger), não faz diferença usar IbdtsPagamentosCODIGO.asinteger ou IbdtsPagamentos.fieldbyname(´CODIGO´).asinteger, visto que a memória já está alocada. o que você perceberá é que se você usar IbdtsPagamentosCODIGO.asinteger o retorno da informação será mais rápido porque o conteúdo já estará alocado na memória, enquanto que, com o uso de IbdtsPagamentos.fieldbyname(´CODIGO´).asinteger o dataset irá fazer uma varredura na lista de campos até encontrar o campo informado - ´CODIGO´ - e só então irá retornar seu valor.
se você NÃO persistir os campos, com certeza alocará menos memória e terá de usar somente o esquema IbdtsPagamentos.fieldbyname(´XXX´).asXXX.
2o.
no caso de apenas uma linha de comando:
if ... then [comando] else [comando];
no caso de mais de uma linha:
if ... then begin [comando1]; [comando2]; end else begin [comando1]; [comando2]; [comando3]; end;
explico:
se sua condição tem apenas uma linha de resposta, como você faz?
if Valor <= 0 then ShowMessage(´Deve ser informado um valor!´) else if Valor >= 100 then ShowMessage(´O valor deve ser MENOR que 100!´);
ou
if Valor <= 0 then ShowMessage(´Deve ser informado um valor!´) else if Valor >= 100 then ShowMessage(´O valor deve ser MENOR que 100!´)
???
eu uso a primeira forma, então, pra mim, somente o comando em si (if..then ou else) deve estar na linha, visto que [i:e64f0204e0]begin...end[/i:e64f0204e0] são utilizados para conjuntos de comandos. eu vejo isso nas funções e procedimentos do Delphi.
[i:e64f0204e0]procedure TForm1.Button1Click(Sender: TObject);
begin
end;[/i:e64f0204e0]
e não
[i:e64f0204e0]procedure TForm1.Button1Click(Sender: TObject); begin
end;[/i:e64f0204e0]
em todos os exemplos mostrados na ajuda do Delphi o [i:e64f0204e0]begin[/i:e64f0204e0] está sempre na linha seguinte, e é esse o padrão que eu uso.
agora, se você trabalha com uma equipe, o bom mesmo é seguir o padrão adotado pela equipe.
GOSTEI 0
Pedroso
12/03/2008
1º
IbdtsPagamentosCODIGO.asinteger
Mesmo que se fale em persistencia, não é a forma mais adequada. O fato de demorar mais é que na realidade é feita uma requisição ao bd. Quando aplico o fieldbyname estou fazendo uma referencia a Classe TDataSet.
IbdtsPagamentosCODIGO.asinteger
IbdtsPagamentos.FieldValues[´CODIGO´];
IbdtsPagamentos.Fields[1].AsString;
IbdtsPagamentos[´CODIGO´];
Existem outras formas de chamar o campo alem destas. O problema esta no retrabalho. Toda a vez que voce tiver que mudar um campo de tamanho ou criar um novo será obrigado a fazê-lo no DataSet tambem. E no codigo. O fieldbyname necessita apenas no codigo. É obvio que os dois métodos tem suas aplicações. Eu uso DataWare mas estou migrando para persistencia.
Criar um ponteiro para o dataset ou seja bdtsPagamentosCODIGO.asinteger , é mais rapido na aplicação do que fieldbyname claro ??? O que devemos avaliar que isto acontecia muito na época de BDE quando existia os arquivos em disco servindo de cache para cada aplicação. Nos SGDB´s tambem existe cache porem mais rapido e paginado. O que nos faz pensar , qual a distancia entre ponteiro e fieldbyname. Eu diria ... no tempo de requisição. O Ponteiro aponta para o campo diretamente , enquanto o fieldbyname procura o campo na query. O que não faz do FieldByName uma carroça. Mas auxilia na abstração quando falamos em projeto. Mas se vamos falar realmente em grandes projetos. Acredito que devamos partir para o lado de persistencia onde ponteiro e referencia não tem muito espaço.
Já o fato de IbdtsPagamentosCODIGO.asinteger consumir mais memoria isto é verdade, Voce obriga o compilador a criar ponteiros (que consomem memoria) para a aplicação. Ai vão me dizer ´Nos dias de hoje onde memoria custa pouco não tem problema´. Eu diria a favor do fieldbyname: ´Nos dias de hoje onde temos processadores tão poderosos que não tem problema´. Desenvolvo desde o CP500 , me desculpem ... para mim memoria sempre teve seu valor. É a nestas pequenas diferencas é que notamos a performance.
Ja fiz testes na versão 3 e 5 do delphi com fieldbyname e Fields e sinceramente a diferença foi tão pequena que preferi ver meu codigo com uma leitura mais facil. Acredito na boa reutilização do código , nas boas praticas de desenvolvimento, no crer e tentar entender o compilador ...... Amem.
O Estanieski trabalha comigo , antes que alguem apele para chefe turrão. Estava apenas brincando com ele. E falando a verdade tambem.
IbdtsPagamentosCODIGO.asinteger
Mesmo que se fale em persistencia, não é a forma mais adequada. O fato de demorar mais é que na realidade é feita uma requisição ao bd. Quando aplico o fieldbyname estou fazendo uma referencia a Classe TDataSet.
IbdtsPagamentosCODIGO.asinteger
IbdtsPagamentos.FieldValues[´CODIGO´];
IbdtsPagamentos.Fields[1].AsString;
IbdtsPagamentos[´CODIGO´];
Existem outras formas de chamar o campo alem destas. O problema esta no retrabalho. Toda a vez que voce tiver que mudar um campo de tamanho ou criar um novo será obrigado a fazê-lo no DataSet tambem. E no codigo. O fieldbyname necessita apenas no codigo. É obvio que os dois métodos tem suas aplicações. Eu uso DataWare mas estou migrando para persistencia.
Criar um ponteiro para o dataset ou seja bdtsPagamentosCODIGO.asinteger , é mais rapido na aplicação do que fieldbyname claro ??? O que devemos avaliar que isto acontecia muito na época de BDE quando existia os arquivos em disco servindo de cache para cada aplicação. Nos SGDB´s tambem existe cache porem mais rapido e paginado. O que nos faz pensar , qual a distancia entre ponteiro e fieldbyname. Eu diria ... no tempo de requisição. O Ponteiro aponta para o campo diretamente , enquanto o fieldbyname procura o campo na query. O que não faz do FieldByName uma carroça. Mas auxilia na abstração quando falamos em projeto. Mas se vamos falar realmente em grandes projetos. Acredito que devamos partir para o lado de persistencia onde ponteiro e referencia não tem muito espaço.
Já o fato de IbdtsPagamentosCODIGO.asinteger consumir mais memoria isto é verdade, Voce obriga o compilador a criar ponteiros (que consomem memoria) para a aplicação. Ai vão me dizer ´Nos dias de hoje onde memoria custa pouco não tem problema´. Eu diria a favor do fieldbyname: ´Nos dias de hoje onde temos processadores tão poderosos que não tem problema´. Desenvolvo desde o CP500 , me desculpem ... para mim memoria sempre teve seu valor. É a nestas pequenas diferencas é que notamos a performance.
Ja fiz testes na versão 3 e 5 do delphi com fieldbyname e Fields e sinceramente a diferença foi tão pequena que preferi ver meu codigo com uma leitura mais facil. Acredito na boa reutilização do código , nas boas praticas de desenvolvimento, no crer e tentar entender o compilador ...... Amem.
O Estanieski trabalha comigo , antes que alguem apele para chefe turrão. Estava apenas brincando com ele. E falando a verdade tambem.
GOSTEI 0
Pedroso
12/03/2008
Ja referente a identação de codigo, é como emerson.en disse .... ele usa daquela forma. Nossa equipe usa de outra forma. Por que no Delphi se usa assim não quer dizer que seja um padrão a ser usado e nem que pode ser chamado de padrão. Mesmo porque gera uma linha a mais no codigo desnecessáriamente.
Neste caso não sei se o compilador trata no assembly. Mas vlw ... é bom descutir.
Neste caso não sei se o compilador trata no assembly. Mas vlw ... é bom descutir.
GOSTEI 0
Emerson Nascimento
12/03/2008
Ja referente a identação de codigo, é como emerson.en disse .... ele usa daquela forma. Nossa equipe usa de outra forma. Por que no Delphi se usa assim não quer dizer que seja um padrão a ser usado e nem que pode ser chamado de padrão. Mesmo porque gera uma linha a mais no codigo desnecessáriamente.
Neste caso não sei se o compilador trata no assembly. Mas vlw ... é bom descutir.
o compilador trata isso, sim. compile um programa que tenha um trecho de código qualquer, por exemplo, um try...except
try
StrToFloat(Edit1.Text);
ShowMessage(´Você digitou um valor numérico´);
except
ShowMessage(´Você digitou um valor alfanumérico´);
end;depois altere para
try
begin
{aqui será avaliado o valor digitado}
StrToFloat(Edit1.Text);
{se o comando acima for válido, será exibida a msg abaixo}
ShowMessage(´Você digitou um valor numérico´);
end;
except
{essa msg será exibida caso haja algum erro}
ShowMessage(´Você digitou um valor alfanumérico´);
end;
note que no segundo exemplo, além de linhas em branco e dos comentários, ainda tem um [i:688208e625]begin..end[/i:688208e625] a mais, porém o compilador trata os dois códigos da mesma forma.
GOSTEI 0
Pedroso
12/03/2008
Emerson , desculpe. Não me expliquei compreensivamente. Na realidade não sei como o compilador do delphi averigua como adotar o melhor caminho pro codigo, offset do codigo, avaliação do tipo de processador, que tipo de ponteiro. Se ele averigua se o segment do codigo begin end é vinculado a condicao ou se é com ponteiro ... estas coisa la em assembly é que realmente eu não sei. Mas ja aconteceu nos tempos aureos .... (Quando se programava de verdade!) em C e Assembly que se deixasse um espaçamento grande entre uma condição ou loop , etc , poderia (Não é regra) gravar tambem um daqueles caracteres especias ..... ai qdo vai compilar BUM!!! Fica horas pra descobrir o que foi ..... já aconteceu com Delphi 2x é claro parece pouco, Duas vezes em 12 anos d delphi ..... mas aconteceu. Imagina ter que passar dias pra descobrir que é este o problema dependendo do tamanho do codigo. En fim ..... eu ultilizo por varios motivos. Um por que acho mais legivel , e bla bla bla bla ...... e por este ultimo que falei. Vamos acabar com este tópico .... ta parecendo que um ta querendo dizer que sabe mais que o outro e ta charope. Obrigado por ter respondido.
GOSTEI 0
Emerson Nascimento
12/03/2008
rsrrs
beleza. não quero saber mais que ninguém.
eu só estava ´palpitando´....
:D
beleza. não quero saber mais que ninguém.
eu só estava ´palpitando´....
:D
GOSTEI 0