Investigando un memory leak en cocos usando objgraph

Issue 169 en cocos reportaba un memory leak usando tilemaps. El reporte inicial era muy bueno (gracias davexunit !), en tanto que incluía un bugdemo simple; lo simplifiqué un poco más eliminando dos clases de la situación.

En esencia, si se definía una escena usando ciertas clases, cuando se hacia un loop creando una nueva instancia de la escena que reemplazaba la anterior como la activa, la memoria crecía sin limite.

El script no retenía referencias directas a las escenas reemplazadas, así que quedaba alguna en cocos o en pyglet, o bien había ciclos uncolectables.

Ahora bien, una de las clases es relativamente compleja, así que no quería empezar a mirar el código todavía; lo que hacia falta era algo que apuntara mas concretamente a las partes responsables.

Buscando un poco encontré objgraph, una pequeña herramienta que informa acerca de los objetos que python tiene en memoria.

Mejorando código

english version

En la última entrada del blog habiamos quedado en que los sprites de cocos 0.4.0 eran bastante mas lentos que los de pyglet 1.1.4. Veamos si se puede mejorar los sprites de cocos.  

Por dónde empezar ?
Python tiene de fábrica el modulo cProfile, asi que agrego unas pocas lineas en cada script para saber cuánto tiempo se gasta en cada parte del código.

Esto me deja con un montón de mediciones; para explorar el conjunto de estadisticas uso RunSnakeRun, un visualizador de estadisticas cProfile.
Lo que hace es dibujar el call tree en forma de cajas anidadas, con area proporcional al tiempo consumido.

Jugando un poco con las opciones de visualizacion obtengo un par de imágenes que parecen interesantes; combinadas en una y anotadas se ven así:

performance de sprites con cocos y pyglet

english version

Cuántos sprites puedo mostrar al mismo tiempo sin que se caigan mucho las fps ?
Que puedo hacer para mejorar el rendimiento ?
Hago un caso testigo, mido y veo que conclusiones puedo sacar.

Escena testigo, en pseudocódigo:

• estado inicial: se crean n bolas con una posición y velocidad mas o menos aleatoria; la posición inicial cae dentro del rectángulo visible de la pantalla.
• update(dt): en cada update, cada bola actualiza su posición con el clásico
  si la bola tocó el borde, rebota de modo que no salga de pantalla

Screenshot

blog, código fuente bonito

Para coloreado de sintaxis lo que mas aparecía nombrado era SyntaxHighlighter en la versión 2.
Actualmente está en la versión 3.

Las instrucciones para como usarlo desde blogger que son claras y resultaron bien están en Installing SyntaxHighlighter to blogger...

Hay dos maneras de incluir fragmentos de código:
Usando pre:

<pre class="brush: js">
    /**
     * SyntaxHighlighter
     */
    function foo()
    {
        if (counter <= 10)
            return;
        // it works!
    }
</pre>

Usando script - CDATA:

<script type="syntaxhighlighter" class="brush: js"><![CDATA[
  /**
   * SyntaxHighlighter
   */
  function foo()
  {
      if (counter <= 10)
          return;
      // it works!
  }
]]></script>

que se verá como

/**
     * SyntaxHighlighter
     */
    function foo()
    {
        if (counter <= 10)
            return;
        // it works!
    }

Usar pre es mas seguro, pero hay que escapar al menos los 'mayor que'.
CDATA no requeriría escapar nada, pero tiene los inconvenientes:
lectores RSS normalmente descartan los 'script'
varios navegadores terminan (equivocadamente) un script si encuentran un cierre de script dentro de un CDATA.
Si el codigo a mostrar no usa ese tag y podemos vivir con el inconveniente RSS, la forma CDATA es mucho mas cómoda.

El lenguaje se especifica con el valor de 'brush' ; hay bastantes disponibles. Aqui probablemte alcanzará con c, cpp, py, python, js, diff, patch, css, plain, xml xhtml xslt html

Conviene recortar un poco el jscript que metemos en el template para que solo cargue los lenguajes que precisamos.

Como comentario, encontré una mención de otro highlighter, hecho por google: Code highlighting on blogger

PD: al menos en noviembre 2010 si habilito spellchecker en el editor, me ensucia los CDATA.

blog , primeros ajustes

Bueno, el tema de templates resulta ser mas complicado de lo que parecía.
Hace algunos meses blogger agregó un sistema de templates nuevos y la situación parece ser

•  el editor de templates no enlaza con ciertas propiedades de los templates viejos.
•  el editor de templates es muy limitado, especialmente en lo que hace a layout, y concretamente para variar el tamaño de relativo de las divs.
•  para ajustar tamaños  hay que editar el html - css - xml asociado, y no es muy claro qué cambiar.

Para hacer fluido la columna de entradas del blog me sirvió la pagina Blogger Feature Suggestions & Feedback - Fluid templates

Para explorar un poco el template bajé firefox y el add-on firebug, que muestra qué partes del html - css afectan una zona de la vista.

Algo básico que quería lograr es tener un buen ancho en la columna de los post, para que el código fuente mostrado allí se vea bien. Y que ese sector fuese de ancho fluido.
Un poco de tocar el código y limitando el ancho de la sidebar mejoró la situación, pero todavía falta investigación para tener un balance agradable entre margen izquierdo - separador hacia sidebar - margen-derecho.

Ajusté un poco los colores y fuentes; allí si el editor funciona. Todavía se puede mejorar.

Como parece que ajustar el aspecto del blog va a llevar bastante experimentación hice un repo Mercurial, no solo para poder recuperar sino para poder hacer diffs entre versiones interesantes.

empezando a bloguear

No teniendo experiencia en hacer blogs, me voy anotando que es lo que hago, para futura referencia.

Requisitos

• Mostrar fragmentos de código tiene que ser fácil; ademas tiene que ser funcional en el sentido que copiar y pegar funcione para el lector.
• Tiene que ser posible organizar en forma relativamente sencilla un articulo que incluya código, texto e imágenes.
• Tiene que tener flexibilidad para especificar mecanismos de navegación. Idealmente ademas de tags y buenas búsquedas tendría que permitir una pagina o paginas donde se pueda organizar jerarquicamente la navegación.
• Tiene que haber mecanismos para importar y exportar contenidos.
• Backup local y recuperación desde backup local.
• Acceso programático es importante.
• Use algún sistema para separar el contenido de la presentación, por ejemplo templates, que permita ir ajustando la presentación sin necesidad de editar cada pagina.
• Debe ser posible encontrar artículos 'como hacer yyy en un blog marca zzz'.

Seleccionando un proveedor

• Buscando por la condición de mostrar fragmentos de código, en stack overflow los dos mas mencionados eran blogger y wordpress. 
• Cada uno tiene dos versiones básicas, la vainilla, que es la hosteada gratis en el sitio, y la custom, donde hay que tener hosting propio o servicio pago.
• Por sencillez me interesa la vainilla.
• En paginas de como hacer esto u aquello, en wordpress hay muchos hits para la version en que uno mantiene su propia instalación del software base (wordpress); esto haría mas difícil encontrar info relativa a la versión vainilla.
• Para blogger parece haber mas blancos para la versión vainilla.
• Muestras de como incluir fragmentos de código en blogger parecen sencillas.
• Ademas ofrece importar, exportar, backup local, acceso programático.

Hay variedad de layouts en las paginas que vi, varios de los cuales ofrecen una presentación limpia y agradable de los contenidos.