Hola a todos, alguien podría explicarme cual seria el problema o la penalización en el rendimiento al utilizar variables globales en memoria por sobre las variables locales? los valores de las mismas no se limitan solamente al cache del cliente?.. o sea la máquina del cliente. y si sobre todo es una aplicación monousuario que inconvenientes tendría?
Digo o pregunto por que he leído varios post en el que aconsejan no utilizar tantas variables globales, pero si están son en memoria ?.. tambien lo pregunto porque cuando empece a trabajar con velneo y la herramienta estaba un poco limitada y yo también en mis conocimientos , comencé a utilizar en las primeras aplicaciones infinidad de variables globales. las aplicaciones están trabajando y que yo me entere no han tenido problemas… pero debo optimizarlas?.
Hoy día ya aprendí a declarar manejadores de objetos y pasarles valores a sus variables locales… pero lo ya hecho corre algún peligro???
En principio no debe haber diferencias de rendimiento al utilizar Variables Globales en Memoria o Variables Locales. Son ambas valores almacenados en la memoria de la máquina cliente o servidor. En realidad las Variables Locales son locales al objeto donde se definen y las Variables Globales en memoria son locales a la instancia de vClient o vServer donde se usan.
Una desventaja de usar las Variables Globales es que no se pueden pasar directamente entre el cliente y servidor cuando se ejecuta un proceso en 3º plano. Un determinado proceso que use Variables Globales en memoria tendrá que comprobar siempre si es ejecutado en 1º plano o 3º plano para asegurarse de que está leyendo la Variable Global correcta.
En resumem, a efectos de rendimiento de acceso no creo que haya diferencia, pero si usas Variables Locales estarás implementando en tu aplicación la encapsulación de objetos, lo que redundará en una mayor calidad del código.
En rendimiento como tal no pierdes nada, el verdadero valor de las variables locales es el orden y la mantenibilidad de tu aplicación, como bien dijiste en v6 tocaba manejar todo apunta de variables globales en memoria y era un tanto caotico si no tenias un sistema de nombramiento estandarizado, en v7 usando variables locales todo queda englobado en el objeto que tiene la lógica y no tienes que mantener estados gloables con lo perjudicial que es eso en cualquier lenguaje, lo único en performance que se me ocurre es que seguramente se disminuye el consumo de memoria pues sin saber los internals de v7 asumo que ya con el objeto cerrado todo las variables se las lleva el Garbage Collector, pero es mera especulación y no creo que sea mucho.
Ahora es cierta que en varias ocaciones es útil usar las variables en memoria y no hay problema en que las uses pero solo cuando realmente necesites manejar en estado gloabal para la aplicación.
Si te sirve de sugerencia yo organice algo intermedio, es manejar las variables de session en un objeto JSON almacenado en una sola variable global en memoria, así puedo ir creando variables en el código cuando lo necesite sin necesidad de crear los objetos como tal, en mi caso me has sido muy útil para la gestíon de permisos pues al momento de la carga del app leo los permisos del usuario los guardo en un JSON y cada vez que necesite consultar los permisos accedo a la variable dinámicamente y no tengo que hacer peticiones al DB.
Yo asumo que las Variables Globales en Memoria son las Variables Locales del objeto Aplicación, y como el objeto aplicación es accesible siempre, por esa razón se llaman Globales.
La limitación de Velneo es que una variable global no pueda ser de tipo objeto, y de esta forma encapsular funcionalidades globales como la gestión de permisos, gestión de sendas, …
Ahora tenemos que solventar esta “limitación” agrupando las funciones y procesos en una carpeta del proyecto. La carpeta simula el objeto global y las funciones y procesos son los métodos. Las variables globales en memoria son las propiedades.
Otra limitación de Velneo es la creación dinámica de variables en tiempo de ejecución. Tú has solucionado esta “limitación” mediante el uso de Strings con contenido estructurado (JSON en tu caso). Me imagino que usas JavaScript para gestionar el String JSON. La pregunta que surge es: ¿es más óptimo usar directamente las variables globales de Velneo o gestionarlas dinámicamente con JavaScript con la sobrecarga que eso conlleva?
Yo estoy empezando con Velneo y todavía estoy buscando un método para intercambiar parámetros entre un objeto de Velneo a otro y entre diferentes planos de ejecución. Quiero evitar la tediosa tarea de escribir largas listas de comandos Set Variable Local de Objeto. Desde luego la forma más elegante es usando strings JSON.
Así que no estaría mal que Velneo incorporara funciones “nativas” para poder crear, mantener y parsear strings JSON. ¡Viva el código nativo!
De esta forma un proceso que recibe y entrega JSON se puede usar tanto en Aplicaciones Velneo nativas como ser consumido remotamente por otras plataformas.
leer variable global en memoria => 0.1 Milliseconds
leer variable global JSON => 3 Milliseconds
aunque como vez la diferencia es grande entre ambas, los tiempos son sobrados en accesso, por ejemplo en mi caso para gestión del estado de un board, los permisos, etc; un tiempo de accesso de 3 Ms es muuuuuuucho más que suficiente.
Efectivamente, el acceso nativo a cualquier objeto en memoria siempre será mucho más rápido.
Por esa razón, si buscamos optimización, es lógico que Velneo se centré en mejorar estos aspectos tan básicos en el diseño de nuestras aplicaciones. De momento tendremos que improvisar soluciones más o menos acertadas.