Ir al contenido principal

Mejoras de performance en el U2 del IDE de la X

En el U2 de GeneXus X se incluyeron varias mejoras, algunas especificamente orientadas a mejorar la performance del IDE. Entre ellas se cambió el modo en el cual se carga el Winte y los generadores. En lugar de ser cargado cada vez, se deja residente en memoria (un demonio) de modo que la próxima vez que se especifique/genere un objeto o grupo de objetos, dicho proceso sea mucho más rápido.



Para mí es un poco difícil (no imposible) hacer mediciones "científicas" sobre este punto porque no se trata de un build all o rebuild all o tareas de msbuilds que se puedan marcar con "timestamp" fácilmente sino es la propia utilización del IDE y la "sensación" más que una medición exacta.

Mi sensación entonces es que realmente mucho más "ágil" el proceso de edición-especificación-prueba-edición... que en sus versiones anterior. Como dice un amigo: "es mucho más fácil hacer eficiente algo que es eficaz que hacer eficaz algo que es eficiente", en realidad lo dice más "criollo": "es más fácil hacer andar rápido algo que anda bien que hacer andar bien algo que anda rápido"

Obviamente esto  de los demonios en memoria consume más de la misma, tampoco tengo mediciones "cientificas" pero aparecen como MSBuilds consumiendo entre 80 y 200 megas de memoria. Como siempre, dependerá de qué máquina tengo, si el SQL Server está local o en un Server, cómo tengo configurado ese SQL Server (memoria limitada o no), etc. Para quienes tengan problemas con la memoria utilizada, pueden volver al esquema anterior (tools/options/build y ahi tienen "close specifier" y "close generator")

Tip

Para finalizar un tip de algo disponible a partir del U2 también, GeneXus se puede ejecutar con la opción "/MeasureCommandTime" es decir algo como:

"c:\GeneXus\genexus.exe" /MeasureCommandTime

si se ejecuta de ese modo, entonces en la ventana de output (general) aparecerán mensajes del estilo:

---> Command: RebuildAll - Elapsed time: 00:00:00.6212445
---> Command: AfterBuildCommandWrapper - Elapsed time: 00:01:54.0176120

Esto en buen romance significa que demoró 1:54 minutos en hacer un rebuild de una KB que tengo (es chiquita, 30 objetos).

Del mismo modo aparecen muchas más operaciones, por ejemplo, al salvar un objeto dice:

---> Command: Save - Elapsed time: 00:00:01.6181117

En fin, no soy un especialista, solo un simple usuario pero capaz el tip le puede servir a alguien en algún escenario.

Comentarios

Entradas más populares de este blog

Abrir links con aplicaciones nativas y no el browser (deeplinking)

El problema que tengo con algunas aplicaciones Android/iOS es que cuando recibo un link por algún medio (mail, tweet, etc) al abrirlo me lo abre con el browser, en lugar de abrirlo con una aplicación nativa asociada a ese “contenido”. Por ejemplo, si recibo un link a un tweet espero que lo abra con alguna aplicación de twitter que tenga instalada y no con el browser. De modo análogo si recibo un mail con una nota de prensa de un medio X y tengo la aplicación de ese medio X instalada, espero que el link lo abra con la aplicación nativa y no con el browser. Lo mismo quisiera con mi aplicación de "banking" o cualquiera que tenga instalada y sepa manejar ese "contenido" (link). Los motivos son bastante obvios pero los resumo en: la experiencia de usuario es mucho mejor en la aplicación nativa que en el navegador. Parte importante del tema es que el mismo link sea válido tanto para ver el contenido en el browser como para verlo en la aplicación, porque como prove...

Mi primer chatbot con whatsapp

No voy a hacer "apología de whatsapp" pues es claro para todos que es una herramienta de comunicación que todo el mundo (al menos occidental) tiene y usa a diario. Siendo así ¿que tal si mi aplicación pudiera responder por ese medio? ¿Qué skills necesitaría? ¿Qué otros recursos? Revisé algunos contenidos al respecto, por cierto los recomiendo, especialmente los producidos en el GX29:  https://meetings.genexus.com/2019/sessions/chatbots Es tremendo lo que se puede hacer alrededor del tema. Sin embargo lo que yo quería era algo bien sencillo, no quería tanto la parte de NLP (PLN), IA, etc que es un camino muy interesante pero que implicaba más trabajo y lo mio era explorar, divertirme, hacer algo útil y aprender en el camino (algunos le llaman "procastinar":)). Quería probar la utilidad de "dialogar" con mi aplicación vía Whatsapp, generar otras ideas a partir de ver y sentir algo funcionando, resolviendo un problema real, un prototipo de bajo costo....

4 Pasos para la toma/ejecución de decisiones

(Habia escrito toda una argumentación pero me quedó muy largo así que vamos al grano) En algunas situaciones me pasa que se mezcla la toma de decisiones con su, necesariamente posterior, ejecución y termina en un desastre porque se implementa lo que no se decidió o no se implementa lo que sí se decidió, etc. Sobre todo pasa cuando se trabaja en equipo y para algunos se está en la etapa de decisión, para otros en ejecución y en cierto modo eventualmente se está resolviendo un problema del cual estamos cambiando la letra o por lo menos dudando de ella. En resumen: decisión y ejecución van de la mano. No significa que la ejecución sea inmediata ni esté perfectamente detallada, que no cambiemos la decisión una vez que estamos ejecutando, pero si no van de la mano suenan a las decisiones de "año nuevo" (comer mejor, hacer más deporte, etc). Hay mucho escrito sobre buenas decisiones, proceso para eso, proceso de planificación, ejecución, seguimiento, actores a involucrar, ...