#VemProgramador
Bom, uma das coisas que tem sido sempre um problema, e provavelmente vai continuar sendo um problema para sempre, é a geometria computacional. A geometria de todas as superficies estavam em hardcode.
Hardcode?
Hardcode é quando você coloca dados de objetos diretamente na memória do programa e não em uma especie de arquivo. Imagina você colocar os dados de uma tabela de um banco de dados direto no código. O que isso significa?
Isso significa que, se você quiser reiniciar o programa com alguma nova modificação, você vai ter que compilar o programa todo de novo pra depois rodá-lo, pois ele está carregando os dados direto na memória. Ler um arquivo é essencialmente ler algo do HD e colocar na memória, e é essencialmente isso que você faz quando você manda executar um programa. A unica diferença é como você o faz.
Então eu criei um leitor de geometrias, Ele lê um arquivo que tem que estar formatado corretamente(caso contrário ele não vai nem continuar rodando), E já carrega as geometrias na memória, ou seja, se eu precisar mudar a geometria de alguma superfície, eu apenas mudo o arquivo e não preciso compilar o código todo de novo.
Isso é bom. Obviamente o trabalho de escrever a geometria para depois jogá-la no arquivo continua horrendamente complicada, mas pelo menos não tenho que ficar compilando o código todo de novo. E bom, é mais facil escrever na sintaxe simplificada do arquivo do que descrever a superfície direto em código C++.
Isso resultou na codificação da Gaua. Agora temos que realizar os seguintes passos:
- Criar um leitor de dados, similarmente ao de geometrias, para ler os dados brutos dos objetos.
- Criar uma melhor abstração de mensagens para facilitar as modificações na camada de rede.
- Documentar o código(Trabalho facilitado pelo Doxygen)
- Terminar de escrever a dissertação que acompanha o projeto.
Bom, acredito que deve ser mais fácil agora, já que um arquivo pode demorar a compilar, acredito eu, que com essas informações no próprio arquivo deveria demorar ainda mais, não?
ResponderExcluirVamos por partes.
ExcluirPopular dados em hardcode vai fazer com que o compilador leve mais tempo processando o código fonte. Ou seja vai demorar mais a compilar. Isso já foi um problema no início da computação. Hoje em dia tudo compila rapidinho.(Óbvio que para uma massa de dados grande essa diferença vai começar a ficar significativa)
Mas esse é o preço que você pode pagar pelo desempenho. Dados "Hardcodeados" já são inseridos diretamente na memória. É um arquivo a menos para o sistema operacional trabalhar. Quanto mais dados em arquivos externos o seu programa precisa, maior tende a ser a lentidão dele, pelo menos para iniciar. Depois disso deve voltar a funcionar normalmente.
Ficar acessando arquivos é custoso. A memória principal(RAM) é muito mais eficaz que a memória secundária(HD). Sendo que para processar o dado, ele sempre vai ser carregado do HD para a memória principal. Isso torna aplicações que ficam fazendo alterações em arquivos mais lentas. A MinArena, em todo o caso, só vai precisar ler qualquer arquivo externo uma vez apenas. É um preço pequeno de desempenho a se pagar pela facilidade de alteração de dados.