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

¡A la salud de mi KB!

Es bueno, especialmente en "bases de conocimiento" (KB) que han pasado por varias versiones de Genexus, chequear su "estado de salud". En este sentido KBDoctor  es una herramienta que ayuda mucho, principalmente desde el punto de vista del "modelo" Genexus (atributos, calls, definiciones de variables, etc) representado en una KB. También es útil revisar la salud de los archivos que lo soportan. Hasta la 9.0 eran archivos C-tree (los famosos .DAT) que tenían indices (los famosos .IDX) y teníamos en "rebuild -y" que mejoraba esos archivos y sobre todo reconstruía los indices. A partir de la X las KBs se almacenan en MS SQL Server por lo cual la administración de la misma pasó de ser un "file server" a un "database server". En este sentido algo que me ha dado muy buenos resultados es el "CheckKnowledgeBase".

Rocha:Constantes tipo fecha

En la Rocha se soportan constantes del tipo fecha o fecha-hora con formato ANSI/ISO (AAAA-MM-DD HH:MM:SS).  Tecnicamente (Sintáxis): <date>::=    [0-9]{1,4}"/"[0-9]{1,2}"/"[0-9]{1,2} | [0-9]{1,4}"."[0-9]{1,2}"."[0-9]{1,2} | [0-9]{1,4}"-"[0-9]{1,2}"-"[0-9]{1,2} <hms>::=    [0-9]{1,2}[ap] | [0-9]{1,2}":"[0-9]{1,2}[ap]? | [0-9]{1,2}":"[0-9]{1,2}":"[0-9]{1,2}[ap]? <constant> ::=   "#"<date>"#" | "#"<date> <hms>"#" | "#"<hms>"#" Funcionalmente Se pueden utilizar esas constantes en las reglas, eventos, propiedades, etc (todo lugar donde se utilice el parser): Algunos ejemplos básicos: &FechaInicial=#2007-01-01# &FechaHoraInicial=#07-1-1 11:15a# &HoraInicial=#11a# Me parece bueno no tener que escribir funciones (CTOD, TTOC) sobre constantes tipo char para lograr una fecha y mucho mejor aun en