Bom dia Thalesduarte.
Sem ver o seu código atual fica difícil lhe dar uma sugestão muito assertiva, mas vou tentar.
Se o programa está fazendo o que você pediu (lendo os arquivos), o que você precisa agora é otimizá-lo.
Para entender como isso pode ser feito, convém pensar no que está ocorrendo agora. A forma padrão através da qual um programa acessa um arquivo é:
1. O programa solicita ao Sistema Operacional (SO) que carregue o arquivo inteiro do HD para a memória RAM com a permissão desejada (leitura, escrita, etc).
2. Após o carregamento, o SO libera ao programa o uso dos dados na memória RAM conforme a permissão solicitada.
3. Se houver alteração no arquivo que deva ser salva, o SO reescreve os novos dados da memória RAM para o HD.
O grande problema é que apesar da grande velocidade dos processadores e memórias atuais, o carregamento ainda é muito mais lento, principalmente se o sistema estiver utilizando um HD (hoje existe a opção do SSD, que torna um pouco mais veloz, mas é importante lembrar que ainda assim é MUITO mais lento que a comunicação diretamente entre o processador e a RAM).
Por isso, carregar 500 planilhas é uma tarefa bastante ineficiente para a máquina, principalmente se for de forma sequenciada com outras ações (abre 1, lê 1, abre 2, lê 2, abre 3, lê 3...).
Mas no caso do uso de COM, isso também pode envolver (dependendo do código) abrir e fechar 500 instâncias de um objeto Excel.Application, o que também é bastante ineficiente.
Eu sugiro algumas opções para tentar otimizar esse processo:
Opção 1: Verifique o código COM que está utilizando. Às vezes você está criando 500 instâncias do objeto COM, quando na verdade poderia criar apenas 1 e depois ir abrindo/fechando as planilhas no mesmo objeto. Tente alterar o seu código COM para ser o mais eficiente possível.
OU
Opção 2: Os dados de planilhas de Excel são basicamente arquivos
xml comprimidos (.zip). Sendo assim, você pode renomear qualquer arquivo
.xlsx como um arquivo
.zip e depois abrir as pastas dele para encontrar os arquivos
xml. Dessa forma, não é necessário abrir uma instância do Excel para extrair os dados de um arquivo
.xlsx, desde que você primeiro descomprima ele e depois acesse o xml diretamente.
Isso não deveria ser necessariamente mais rápido do que abrir o arquivo, mas acontece que o processo de descompressão pode ocorrer em paralelo ao processo de leitura dos arquivos
xml (por exemplo, você usa um arquivo .bat com linhas de comando para extrair os arquivos e enquanto isso o script autohotkey vai só esperando os arquivos xml ficarem disponíveis e já vai lendo eles conforme aparecem).
Acho que alguma dessas ideias podem render frutos (mas não posso garantir sem testar). Eu também poderia sugerir uma alternativa de ler apenas parte dos arquivos (alguns comandos permitem ler uma quantidade de bytes sem carregar o arquivo inteiro na memória), mas eu acho que arquivos comprimidos, tal como os xlsx, dificultariam muito esse tipo de algoritmo (ainda assim vale saber que pode ser possível).
Bom dia Thalesduarte.
Sem ver o seu código atual fica difícil lhe dar uma sugestão muito assertiva, mas vou tentar.
Se o programa está fazendo o que você pediu (lendo os arquivos), o que você precisa agora é otimizá-lo.
Para entender como isso pode ser feito, convém pensar no que está ocorrendo agora. A forma padrão através da qual um programa acessa um arquivo é:
1. O programa solicita ao Sistema Operacional (SO) que carregue o arquivo inteiro do HD para a memória RAM com a permissão desejada (leitura, escrita, etc).
2. Após o carregamento, o SO libera ao programa o uso dos dados na memória RAM conforme a permissão solicitada.
3. Se houver alteração no arquivo que deva ser salva, o SO reescreve os novos dados da memória RAM para o HD.
:arrow: O grande problema é que apesar da grande velocidade dos processadores e memórias atuais, o carregamento ainda é muito mais lento, principalmente se o sistema estiver utilizando um HD (hoje existe a opção do SSD, que torna um pouco mais veloz, mas é importante lembrar que ainda assim é MUITO mais lento que a comunicação diretamente entre o processador e a RAM).
Por isso, carregar 500 planilhas é uma tarefa bastante ineficiente para a máquina, principalmente se for de forma sequenciada com outras ações (abre 1, lê 1, abre 2, lê 2, abre 3, lê 3...).
Mas no caso do uso de COM, isso também pode envolver (dependendo do código) abrir e fechar 500 instâncias de um objeto Excel.Application, o que também é bastante ineficiente.
Eu sugiro algumas opções para tentar otimizar esse processo:
Opção 1: Verifique o código COM que está utilizando. Às vezes você está criando 500 instâncias do objeto COM, quando na verdade poderia criar apenas 1 e depois ir abrindo/fechando as planilhas no mesmo objeto. Tente alterar o seu código COM para ser o mais eficiente possível.
OU
Opção 2: Os dados de planilhas de Excel são basicamente arquivos [c]xml[/c] comprimidos (.zip). Sendo assim, você pode renomear qualquer arquivo [c].xlsx[/c] como um arquivo [c].zip[/c] e depois abrir as pastas dele para encontrar os arquivos [c]xml[/c]. Dessa forma, não é necessário abrir uma instância do Excel para extrair os dados de um arquivo [c].xlsx[/c], desde que você primeiro descomprima ele e depois acesse o xml diretamente.
Isso não deveria ser necessariamente mais rápido do que abrir o arquivo, mas acontece que o processo de descompressão pode ocorrer em paralelo ao processo de leitura dos arquivos [c]xml[/c] (por exemplo, você usa um arquivo .bat com linhas de comando para extrair os arquivos e enquanto isso o script autohotkey vai só esperando os arquivos xml ficarem disponíveis e já vai lendo eles conforme aparecem).
Acho que alguma dessas ideias podem render frutos (mas não posso garantir sem testar). Eu também poderia sugerir uma alternativa de ler apenas parte dos arquivos (alguns comandos permitem ler uma quantidade de bytes sem carregar o arquivo inteiro na memória), mas eu acho que arquivos comprimidos, tal como os xlsx, dificultariam muito esse tipo de algoritmo (ainda assim vale saber que pode ser possível).