Fórum Consumo de memória #355261

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.

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.

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.

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
depois altere parae compile novamente.
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.

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.

rsrrs
beleza. não quero saber mais que ninguém.
eu só estava ´palpitando´....

:D