Tengo un programa VBA ejecutándose en mi Ultrabook Acer Aspire S3 de cuatro núcleos. El problema es que sólo utiliza el 25% de la CPU (los otros procesos combinados utilizan ~1%). La computadora portátil ejecuta Windows 8.0. La edición de Excel es 2013 (32 bits). Sólo se utiliza el 55% de la RAM del sistema y Excel utiliza la mitad de ese 55%.
Creo que tal vez solo se use el 25% porque Excel solo usa un núcleo. Sin embargo, no tengo nada que respalde esta teoría. ¿Cómo acelero el programa?
Gracias.
Respuesta1
Parece que el programa que estás intentando usar tiene un solo subproceso, lo que significa que solo puede usar un único núcleo, no sabe que los demás existen. Realmente no existe una forma concreta de acelerar esto, excepto comprar un procesador con una velocidad de reloj de un solo núcleo más rápida o usar un programa que admita subprocesos múltiples.
Respuesta2
Todo lo siguiente se aplica a Excel 2007 y versiones anteriores. De acuerdo con laenlace@Ƭᴇcʜιᴇ007 publicado en los comentarios anteriores, hay soporte nativo para subprocesos múltiples en Excel 2013. Dicho esto, aún se aplica la advertencia de olvidarlo a menos que sea un programador experimentado.
Desafortunadamente, VBA no admite subprocesos múltiples, por lo que sus cálculos de VBA se limitarán a un núcleo de su procesador.
Sin embargo, existe un método avanzado para engañar a VBA para que ejecute varios subprocesos generando archivos VBscript y ejecutándolos simultáneamente. Esto soluciona el problema ejecutando su código fuera del proceso de Excel y permite a Windows administrar los recursos asignados a los diferentes subprocesos.
Dicho esto, lograr que esto funcione probablemente signifique repensar completamente la lógica de su código (es decir, tendrá que descubrir cómo dividir las tareas de una manera que tenga sentido para que se ejecuten simultáneamente), lo que puede muy bien será inviable para su proyecto. Nunca he implementado esto por mi cuenta, así que no puedo ayudarte más que contándote lo que ya te dije.
Sin embargo, si deseas adentrarte en la madriguera del conejo, aquí tienes unapublicación de blog interesanteeso muestra un ejemplo de cómo se hace esto. Tenga cuidado: a menos que sea un programador consumado, es mejor que olvide esta idea y simplemente acepte que VBA se ejecuta en un solo hilo.
Otros recursos en Stack Overflow para los atrevidos:
https://stackoverflow.com/q/19159025/657668
https://stackoverflow.com/q/5721564/657668
Por supuesto, existen otras formas de optimizar su código VBA sin utilizar múltiples subprocesos. Sin ver su código, es imposible hacer sugerencias concretas, pero aquí hay algunos de los sospechosos habituales:
- Cargue datos de su hoja en una matriz para un procesamiento más rápido. Las interacciones con la hoja de trabajo son un cuello de botella importante en la ejecución de VBA y se pueden minimizar trabajando con matrices.
- Un problema relacionado es que Excel vuelve a calcular el libro después de cada cambio realizado en una celda. Esto se puede evitar configurando
Application.Calculation = xlManual. Sólo asegúrese de volver a configurarloApplication.Calculation = xlAutomaticantes de salir de su Sub.
Respuesta3
Como dijeron otros, VBA de forma nativa no es multiproceso. Si desea acelerar, puede considerar escribir funciones definidas por el usuario (UDF) en otro idioma.
Te recomendaría ExcelDNA y usar C# o VB.Net. Son muy fáciles de usar si ya sabes escribir algo de C# y puedes controlar el multiproceso dentro de la UDF.
Respuesta4
Como han dicho los demás anteriores, el subprocesamiento sería la respuesta, pero en realidad no es una solución factible, y la actualización a 64 bits haría una diferencia insignificante. Una cosa que podrías intentar hacer es aumentar la prioridad del proceso, puedes ver cómo hacerlo.aquí.
Es difícil decir si esto hará que su secuencia de comandos sea más rápida o no, ya que puede haber otro cuello de botella en otra parte del programa (por ejemplo, lectura/escritura desde el disco), pero al menos le permitirá a Windows saber que tiene una prioridad más alta que su otros procesos.