[pyar] unittesting performance

[Daniel Moisset]

Yo pense en sugerir eso que dice Claudio, aunque tengo mis dudas de cuan
bien puede andar. Algunos opcodes pueden llamar a builtins que pueden
tardar ridiculamente mucho (sum(lista_larga)) u operadores (elemento in
lista_larga), con lo cual puede ser una medida pobre de perfomarnce. De
hecho, si tu código en python es "eficiente", debería pasar una cantidad
significativa de tiempo en pasos gruesos del bytecode, que es donde ganas
mas performance (porque esos pasos gruesos estan hechos en C y no tenes el
overhead del interprete).

Todo depende de para que querés esto.

Saludos,
    D.


2014-05-09 10:47 GMT-04:00 Claudio Freire <klaussfreire en gmail.com>:

> On Thu, May 8, 2014 at 7:40 PM, Andres Riancho <andres.riancho en gmail.com>
> wrote:
> > No a ambas opciones. Las dos miden tiempo de ejecucion, y como dije en
> > el email anterior eso es exactamente lo que quiero evitar.
>
>
> Si te fijás en nose.tools, tenés set_trace. Eso habilita el tracer (lo
> que usa pdb para hacer paso a paso).
>
> Es posible que con eso puedas contar opcodes ejecutados, porque el
> tracer va a llamar una función (que podés customizar imagino) y en esa
> función podés medir en qué bytecode está (en el frame tenés esa info),
> hacer la resta pertinente e ir acumulando.
>
> No es trivial, pero puede que sea útil.
>
> De hecho, yo haría una función que haga eso, y usaría nose.tools.timed
> customizando el reloj, con un reloj monotónico basado en bytecodes, y
> "listo".
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20140509/bf71ed7a/attachment.html>