Options
– performance and disk – multithread enabled.
Vi properties – execution: para definir em que thread do LV (execution system) e que prioridade tem essa vi.
Cuidado com o compartilhamento de recursos por threads diferentes: pode haver intertravamento, inversão de prioridade ou mesmo a omissão de alguma tarefa (thread starvation).
Monitora utilização de memória e tempos de processamento de cada vi.
I/O – restrinja operações de I/O ao mínimo necessário. Fazer tudo de uma vez só, se possível.
Atualizações de tela (interface com o usuário) – o mais leve possível, simples.
Obs: gráficos sempre redesenham quando recebem novos dados, mesmo que os dados sejam iguais aos dados anteriores.
Evitar sobrepor objetos no front panel.
Sobrecarga de Subvi – a chamada de uma subvi leva algumas dezenas de microsegundos. Em uma única chamada, isso não é significativo, mas deve ser levado em conta se a vi for chamada muitas vezes.
Obs: pra minimizar esse efeito, vá em file->vi properties e selecione para a vi a prioridade de subrotina. Mas subrotinas não podem mostrar front panels, chamar funções de diálogo ou de temporização, nem compartilhar tarefas (multitask) com outras vis.
Loops burros – evitar fazer a mesma operação (obtendo um mesmo resultado) mais de uma vez.
Evitar escrever e ler muitas vezes em variáveis globais, especialmente dentro de um loop. Ao invés de ler e escrever na variável global, usar um shift register para atualizar o valor dentro do loop.
Variáveis locais e globais. Variáveis locais fazem cópias do buffer de dados, ou seja, usar uma variável local equivale a duplicar o controle ou indicador no programa. Isso aumenta o consumo de memória e conseqüentemente diminui a velocidade, especialmente se o dado é grande, como um vetor ou uma waveform. O mesmo ocorre com variáveis globais. Para efeito de performance, ambas devem ser evitadas.
Property nodes and control references. Ambos rodam na thread da user interface. Pra usá-los, uma troca de thread é feita, o que reduz o desempenho. Obs: é pior atualizar um controle com um property node do que com uma variável local. Contudo, se o property node já vai ser usado de qualquer jeito, por outro motivo (por exemplo, pra controlar a visibilidade do controle), então essa consideração não faz diferença, porque o swap de thread já ocorre de qualquer forma. Outra coisa: se no código de uma subvi eu utilizar property nodes em uma subvi, seu front panel será carregado (talvez desnecessariamente) na memória.
Referências de controle servem pra alterar uma propriedade de um controle de dentro de uma subvi. No entanto, se a única propriedade a ser alterada é seu valor, é preferível usar variável global ou uma variável global funcional.
Temporizar todos os loops. Isso permite estabelecer prioridades entre loops. Vale a pena setar um loop até com temporização zero, pois a função de temporização introduz um delay muito pequeno que permite ao processador realizar outras tarefas.
Reentrant Execution. Setada em Vi properties – execution, a execução reentrante permite que a mesma vi seja chamada simultaneamente por dois processos diferentes. Significa que cada instancia da VI terá um espaço de dados diferente. Caso contrário, o espaço de dados da VI é único, não importa de onde ela seja chamada.
Pra ver quanta memória total está sendo utilizada, Help-About LabView. Pra uma Vi em particular, File- Vi properties – Memory Usage (salvar antes de usar esse recurso, pra eliminar “undo’s” da memória).
Uma VI tem quatro partes, que podem ou não ser carregadas na memória:
Quer dizer: se uso mais subvis ao invés de uma grande vi principal, a memória é otimizada, pois deixo de alocar objetos desnecessários na memória.
Vazamento de memória – já é gerenciado pelo LV de forma satisfatória. Uma dica a mais é fechar todas as referências que forem abertas.
Suponha que em um while loop, a cada iteração vou acrescentando um elemento a um array. O processo se estende indefinidamente. A memória será toda tomada. Uma opção mais eficiente é, a cada iteração, ao invés de armazenar o dado em memória, gravar o dado em arquivo. Ainda assim o processo fica limitado à capacidade do disco. Antes, vale a pena perguntar se todos esses dados são realmente necessários. Quase sempre haverá uma solução mais inteligente.
Obs: o interessante desse comentário é que quando uso as funções de gravação em arquivo, posso diminuir o uso da memória.
Obs: é mais eficiente alocar um array por um for do que por um while, pois o LV sabe de antemão no for loop quanto espaço poderá alocar. As duas formas mais rápidas são o initialize array, em primeiro, e o for loop em segundo lugar. Deve-se evitar usar a função build array dentro de um loop, pois a cada iteração será realocado um buffer e todo o conteúdo será copiado para os novos endereços.
Ter em mente que a conversão de tipo sempre realuca buffers. Assim, é preferível converter ponto a ponto do que um array inteiro, do ponto de vista da economia de memória. É importante que o tipo dos controles sejam os mesmos dos dados pra evitar uma outra conversão de tipo!
Bizu:
para visualizar locações de buffers: tools – advanded – show buffer
alocations.
É mais eficiente trabalhar com dados mais simples. Evitar cluster de arrays de clusters, por exemplo, pois ao acessar esses dados complexos é necessário usar muitas funções que realocam buffers.