while True

[tny]

El jue, 09-11-2006 a las 00:18 -0500, Arnau Sanchez escribió:
> tny escribió:
> > Acepto que desde el punto de vista del desarrollo sea más cómodo y clara
> > lo del 'while True:' pero punto de vista de la ejecución prefiero lo de
> > 'x=loquesea\nwhile x:' 
> >
> > Tal vez para enviar un archivo no tenga mucha importancia, pero si puedo
> > escoger me quedo con la opción más rápida. 
> >
> > Ejemplo.
> > ....
> > ....
> > prueba1 tardo 4 segundos
> > prueba2 tardo 6 segundos
> >
> >   
> Indiscutiblemente la primera opción será siempre la más rápida. Pero esa 
> relación 4/6 que obtienes -para hacer un control más fino del tiempo 
> puedes usar time.time()- no es del todo realista, ya que ése es el peor 
> de los casos (el bucle no hace nada). En general, el tiempo dedicado al 
> proceso de los datos será mucho mayor que el del control del bucle, y la 
> mejora que obtengas será casi despreciable.
> 
> En cualquier caso, en este tema soy muy parcial: tiendo a primar 
> claridad frente a velocidad, y mucho más en Python, que es un lenguaje 
> que te obliga a ello de forma natural. Sólo si compruebo que esa 
> preciosa y estilada función es el cuello de botella de mi script 
> intentaré optimizarla (ya sabes, el famoso "premature optimization is 
> the root of all evil")
> 
> En este caso concreto, como dice el FAQ, la cuestión es que repetir esa 
> línea es una fuente de errores: si cambias la forma en que obtienes los 
> datos es probable que te olvides de modificar una de ellas (más aquí, 
> que quedan en extremos opuestos del bucle). En general, si repito líneas 
> (o trozos de codigo) en un programa considero que algo no anda bien.
> 
> Y por último, apelaré al resbaladizo argumento de autoridad: el código 
> de la librería oficial de python está plagado de bucles while True/if 
> not condition/break. ;-)
> > No pretendo discutir por discutir, mi intención es que podamos aprender
> > todos un poco, 
> Por supuesto, de eso se trata. Aunque si no participa nadie más será que 
> no interesa mucho, y si te parece lo dejamos en empate :-)
> > que me saquéis de mi error si estoy equivocado, y mostrar
> > el verdadero camino de la serpiente si soy un iluminado del fósforo
> > verde. XD
> >   
> Pues si tengo que ser yo quien te muestre el verdadero camino de la 
> serpiente, que aterricé por casualidad, con un triple salto mortal, 
> desde el ensamblador x86 directamente en Python... :-D
> 
> salud

Mejor que un empate, ganamos todos.

Hablando de ensamblador...
Se necesita a alguien para programar PICs, concretamente imprimir con un
cabezal de impresión lo que llegue por serie.


El jue, 09-11-2006 a las 11:08 -0500, Gerardo Juarez escribió:
> Interesante tu prueba. La duda que me surge es si, en el contexto real
> en 
> el que correra tu programa, podrias detectar esta diferencia. Porque
> ya en 
> el, tu programa correra con otros procesos, que tal vez le roben
> tiempo de 
> CPU, ademas de latencia en la red, que despues de todo, es el eslabon
> mas 
> debil de toda la construccion que tienes. Yo creo que las variaciones
> de 
> rendimiento que obtendras de una corrida a otra son mayores que la 
> diferencia de un tipo a otro de ciclo. 
> 
> En general, considerando que tu aplicacion hara muchas mas cosas que
> recibir datos, las optimizaciones creo que estarian por otro lado,
> como,
> por ejemplo, encontrar una forma de que la informacion a recibir sea
> la
> menor posible. Por ejemplo, si tienes una capa de compresion en ambos
> lados de la transmision, y dependiendo del contenido y volumen a
> transmitir, puede ser la mejor opcion, aunque a nivel de simples
> ciclos
> por segundo sea mucho mas lenta.
> 
> saludos
> Gerardo 

Yo no soy el de los sockets ;)

Mi trabajo, por el momento, consiste en hacer todo lo posible para poder
utilizar las máquinas que hay allá donde vamos, máquinas de las que no
tenemos ningún tipo de documentación o driver, y que valen demasiado
dinero como para sustituirlas.
 
Para ello tengo hacer, entre otras cosas, muchas fuerzas brutas donde
una instrucción de más puede implicar horas o incluso días de más.

La siguiente fuerza bruta que me toca es justo el caso contrario:
Enviar 2**16 mensajes modificados a una máquina a ver si 'traga' con
alguno...
En éste caso la mayor parte del tiempo se lo lleva la máquina.

Cuando sepa comunicarme con la máquina (de S&B), haré el programa que la
controle (sin ser tan tiquismiquis con la velocidad).
Y antes de tener tiempo para brindar con sidra, vuelta a pelearme con
otra máquina muy parecida, pero de otros fabricantes (telvent).

------------ próxima parte ------------
_______________________________________________
Python-es mailing list
Python-es en aditel.org
http://listas.aditel.org/listinfo/python-es