Problema com desempenho do VB6

[marcos_cav 0]

Olá a todos!

 

A minha dúvida é simples e objetiva: É melhor, falando em desempenho, usar vários timers e colocar tudo num único programa, ou um programa para cada tarefa que preciso fazer?

 

Meu problema é o seguinte:

 

- Tenho uma aplicação feita em vb6, nela estão rodando 5 timers que ficam fazendo atualizações utilizando controles webbrowsers, que usamos para monitorar a atividade de alguns sites.( eles leem o código fonte das páginas, e guardam informações no banco de dados Access).

 

- Para que tudo funcione ao mesmo tempo, colocamos várias instruções DoEvents.

 

- Porém, estou percebendo que a aplicação demora muito e tem muitas vezes que fica parada em uma unica rotina. Pois precisamos que toda a tarefa seja realizada o mais rápido possível.

 

- Eu quero saber se, na questão de desempenho, é melhor eu fazer dessa forma, ou seria mais viável criar um programa em vb para cada tarefa que eu precise realizar? (Seria 1 programa que ira monitorar utilizando somente 1 webbrowser).

 

Nós temos também problema com memória, nosso servidor tem somente 1 GB de memória e fica inviável aumentar. E é nele que fica rodando o programa. Tenho medo de criar vários programas e ele estourar a memória.

[KhaosDoctor 242]

Nenhuma dessas alternativas, o melhor é você trabalhar com Threading, assim você consegue aliviar a pressão da aplicação e passar tudo para a memória do sistema, ai vai depender do hardware que você tem.

[Gustavo Emygdio Barboza 24]

Marcos o vb6 não é multi-thread mesmo com doevents não resolve ... coloque cada time em um EXE separado... e que seu processador não seja de um núcleo só... senão nem vai adiantar fazer em .net ou java ....essas linguagens atendem a questão dos threads mas o hardware tem que acompanhar...

Att;

[KhaosDoctor 242]

Threading não roda em núcleos separados... Ela roda em processos de sistema separados, você não precisa ter vários núcleos para rodar vários processos. Vide o próprio Windows, quando você abre o gerenciador de tarefas, cada um daqueles processos é uma Thread.

[Gustavo Emygdio Barboza 24]

?? tem certeza que cada processo é uma thread? aqueles processos na verdade estão trabalhando em pilha ou fila depende da prioridade... a questão do multi-Threading vinculada a questão do núcleos são que os processos sempre serão balanceados entres eles.... o windows (S.O.) simula um multi-Thread não que seja!! senão só teríamos 1 programa por vez rodando se o processador fosse Singlethread...

 

quando mencionei que o amigo poderia criar vários exes estaria passando a responsabilidade do controle dos processos para o S.O. não para a aplicação que não da suporte... o windows entenderia que seriam 2 programas distintos disputando o processamento com isso se o processador for dual-core ou quad-core a demanda seria distribuída no caso sempre gerenciada pelo S.O.

 

ou entendi errado..?

 

o problema real do Marcos é a base access ... que a mesma tem o limite de 2 gigas mas que começa a corromper 1 giga... imagine 5 programas abrindo e fechando a mesma base ao longo do tempo... isso é ruim....

[KhaosDoctor 242]

Não cara, o processador não interfere nos processos do sistema. Cada thread, ou processo, é como se fosse um novo programa, imagina que você está abrindo um caderno que é seu sistema operacional, cada folha seria um programa, e cada linha desta folha seria uma thread, ou seja, cada programa pode abrir vários processos executando em paralelo.

 

A parte que o SO faz a distribuição deste processos para cada núcleo do processador é verdade, ele divide as tarefas para que ocupem um pouco de cada parte do processador, mas não existem "processadores single thread" todos os processadores são capazes de executar diversas threads ao mesmo tempo independentemente se eles possuem um núcleo ou 8 núcleos. Até poque, na maioria dos processadores atuais, muitos núcleos são simulados e não são literalmente físicos.

 

O desempenho do computador como um todo depende do conjunto do processador e máquina. Mas um programa que divida suas tarefas em um sistema de threading é muito mais eficaz do que um programa que abra outros programas, porque, voltando à analogia do caderno, se o programa tiver sistema de threading, então você estaria usando uma linha para cada thread aberta, enquanto que se você abrisse um exe novo para cada processo você estaria usando uma nova folha do caderno para tal.

 

A questão da base de dados não interfere tanto assim, porque uma abertura de conexão de dados não necessariamente precisa carregar toda a base, ou seja, ele pode abrir a conexão sem carregar dado algum, não há problema nenhum você abrir uma base access de 2GB em cada formulário, o problema estaria se você precisasse recuperar 2GB de dados em todos os formulários abertos.

[Gustavo Emygdio Barboza 24]

Com certeza trabalhar com um programa que trabalha com threads é melhor do que jogar o pepino para o s.o. mas estamos falando de vb6... 5 times num programa só vai acontecer 1 de cada vez "entre aspas" mesmo que pareça que todos estão funcionando simultâneamente por causa do doevents ... com relação ao single core ou thread a idéia é a mesma estava querendo dizer exatamente isso todos os processadores são capazes de simularem várias filas mas graças ao s.o. com relação ao access já conheço bem trabalho com ele desde a versão 2.0 a 1.0 não existia fica mesmo com meu qbasic mesmo já no windows com access 2 foi um salto enorme na produção das soluções .... já trabalhei com programas acccess aclopadas e desaclopadas com banco access e ele sempre me decepcionou pois corrompe de qualquer jeito é claro que o hardware ajudava nisso um desligamento inesperado era o suficiente para ter perdas de dados... agora falando do front do access com outras bases mssql ou Firebird ou PostgreSQL vinculado por odbc muda bastante porque da desenvolver como se fosse as tabelas do próprio access com algumas limitações dos métodos do DAO mas flui super bem... o qual trabalho até hoje... mas trabalho com ASP também hoje já vejo limitações da tecnologia por isso estudo outras linguagens...

[KhaosDoctor 242]

Atualmente a versão do Access não está corrompendo muito mais dados, acredito que esteja na versão 13 se não me engano, ele melhorou muito de lá pra cá.

 

Trabalhar com timers realmente não é um aboa ideia, então você pode usar threads ou então fazer um jogo com os eventos da aplicação para que ele executem o DoEvents em tempos específicos e não toda hora.

[Gustavo Emygdio Barboza 24]

realmente estou trabalhando com access 2000 (MDB) agora é access 2010 (accdb) de fato pode ter melhorado a estabilidade até mesmo por causa do SharePoint que deve-se requerer maior número de conexões simultâneas...

(estou dez anos atrasado rsrs...) na verdade só não precisei mudar pelos novos recursos...

 

confesso que fico receoso em usar o access como base pois quase que tomei um processo por causa disto... o backup automático me salvou, mas além disso tive que migrar os dados para o postgresql com isso nunca mais tive problemas.... o cliente é chato mas é fiel...

[KhaosDoctor 242]

Access só é util em bases de aprendizado.

[Gustavo Emygdio Barboza 24]

hoje em dia eu digo a mesma coisa Access Back-End somente para base de aprendizado...