Os resultados obtidos nos testes anteriores dizem muito acerca do 2ndComing.
A primeira conclusão a tirar é a de que o que demora mais no processo de geração de conteúdo são as trocas de mensagens. Pelos resultados do teste A, em que cada prim era gerado com o envio de uma mensagem, notou-se um fraco uso dos recursos do processador quando comparado, por exemplo, com o teste B em que somente existiu uma troca de mensagens e o resto do teste baseou-se em processamento.
Este facto é particularmente visível quando comparando o teste A com o teste D. No teste A, por cada prim criado é enviada uma mensagem enquanto no teste D é enviada uma mensagem por cada objecto complexo. No fundo, isto quer dizer que no teste D, por cada mensagem são criados cinco prims.
Tabela 27: Comparação dos tempos dos testes A e D Teste Tempo Total Tempo por prim
Teste A - criar 1 prim 105ms 105ms
Teste D - criar 5 prims 107ms 21.4ms
Analisando os dados da Tabela 27 rapidamente se conclui que enquanto no teste A se obteve uma média de 105milissegundos por cada prim gerado, no teste B o resultado foi de 107milissegundos por cada objecto criado. Isto quer dizer que por cada prim criado, o teste D apenas demorou 21.4milissegundo contra os 105milissegundos do teste A. Está aqui bem demonstrado o overhead temporal que as mensagens trazem à criação de conteúdo.
[2ndComing] Startingtime: 6/20/2009 12:55:26 AM [2ndComing] Stop time: 6/20/2009 12:57:22 AM [2ndComing] 00:01:56.5194630
Em termos de consumo de memória, em praticamente todos os testes notou-se um ligeiro aumento do consumo com a realização dos testes. Porém, a maior parte, mais de 95% do total da memória, estava já ocupada na altura do teste.
Os testes relativos ao movimento de prims, testes B e E, são testes com alto teor de processamento e servem apenas para mostrar como se comporta o OpenSimulator e o processador da máquina onde este está a ser executado. Pelos resultados obtidos, apenas se notou alguma perda de fluidez no mundo virtual nos testes de remoção de conteúdo, ou seja, testes C e F. Estes testes requerem muito processamento pois além de ser necessário remover os objectos da cena virtual é também necessário apagá-los da base de dados do
OpenSimulator que acumula alguns objectos e depois os apaga simultaneamente de forma a
aumentar a eficiência. Porém, quando o OpenSimulator executa este processo, em acumulação com os testes que estão a ser realizados, o consumo dos recursos do processador é praticamente total.
Por último, o teste de controlo de tempo da geração de estradas, teste G, mostra que o processo pode, em alguns casos, ser muito demorado. Quanto mais densa for a área que se deseja criar, mais tempo esta levará a ser criada. O resultado dos testes permitiu observar a grande disparidade de tempos necessários para os dois processos que envolvem a criação de estradas: a angariação de informação necessária e o uso da informação para criar conteúdo. O primeiro processo demora bastante mais tempo que o segundo visto toda a informação da zona ser enviada por mensagens HTTP para o 2ndComing. O segundo processo apenas usa a informação necessária de toda aquela que foi compilada no primeiro para gerar conteúdo. O tempo excessivo gasto no envio de todas as informações disponíveis no primeiro processo acabará posteriormente por ser compensado quando outros geradores de conteúdo, como o
BusGenerator, usarem a informação angariada no processo de criação de ruas para criarem os
seus conteúdos. A adição futura de novos geradores de conteúdo poderá também usar esta informação.
Capítulo 6
Conclusão
O tema deste projecto é, sem qualquer dúvida, bastante vasto e vago. As possibilidades de escolha para o conteúdo que se deveria começar por gerar são praticamente infinitas e num projecto limitado no tempo como este, é necessário escolher apenas uma pequena parte dessas. A escolha recaiu sobre a geração de estradas, simulação de movimento de autocarros e objectos com algum grau de complexidade. Com estes três conteúdos tipos de conteúdo distintos consegue-se gerar conteúdo estático e dinâmico.
Para facilitar a futura adição de outros geradores de conteúdo o software foi desenvolvido por módulos, deixando também bastante espaço para a interligação da informação que diferentes módulos transmitem através da centralidade conferida ao
2ndComing.
Os resultados dos testes realizados permitem concluir que o 2ndComing não é muito exigente em termos de consumo de recursos da máquina onde está instalado. Como se viu anteriormente, apenas os testes que exigiam muita capacidade de processamento é que levaram o processador aos limites das suas capacidades. Os únicos testes que conseguiram este feito foram os de remoção de objectos da cena. Esta funcionalidade do 2ndComing será utilizada em ocasiões raras e especiais, pelo que, a momentânea perda de fluidez no mundo virtual não será muito sentida.
As trocas de mensagens entre os módulos são o principal factor no consumo de tempo. Tempo esse que é cada vez mais indispensável para os utilizadores deste tipo de software. O processo de troca de mensagens realizado pelo 2ndComing RoadGenerator é muito intenso e demorado. Porém, as estradas são uma parte fundamental para uma simulação num mundo virtual e a quantidade de conteúdo que se poderá gerar para elas é muito variada. Neste momento apenas o 2ndComing BusGenerator aproveita a informação anterior, diminuindo assim de forma drástica a quantidade de informação que precisa de enviar. No futuro, outros
108
módulos poderão utilizar essa mesma informação e assim compensar o tempo gasto na primeira fase pelo RoadGenerator.
A instabilidade do código do OpenSimulator tornou-se, durante o tempo do projecto, uma contrariedade. As constantes evoluções mexeram em algumas secções importantes que estavam a ser utilizadas neste projecto. Por outro lado, a falta de documentação das funções suportadas pelo OpenSim, bem como as funcionalidades por implementar que de certa forma não ajudaram à evolução do 2ndComing foram outras das adversidades encontradas. Um exemplo dessas funcionalidades não implementadas é a função moveToTarget(targetCoords,
timeToReachTarget). Esta função seria óptima para ser usada nas simulações de autocarros,
porém não foi possível colocá-la operacional.