El 23/10/06, Horst H. von Brand<[EMAIL PROTECTED]> escribió: > Germán Poó Caamaño <[EMAIL PROTECTED]> wrote: > > On Mon, 2006-10-23 at 14:00 -0300, Horst H. von Brand wrote: > > > Juan MartÃnez <[EMAIL PROTECTED]> wrote: > > > [...] > > > > Un lenguaje compilado, en general, siempre (o casi siempre) sera la > > > > mejor alternativa a usar.
No siempre. > > > [...] > > > > Sobre todo si es para un sistema complejo > > > > (un SIA por ejemplo), dado que será mas rapido que un lenguaje > > > > interpretado. No siempre. > > > Lo cual es totalmente irrelevante. Que el SIA se demore 0,5s o 0,01s en > > > responder, si el perejil en la pagina web al otro lado de Chile luego pasa > > > 5s pensando que hacer a continuacion no hace particular diferencia. Si, si > > > tienes decenas de miles de usuarios simultaneos es vital, pero eso se da > > > solo cuando muestran los resultados de las elecciones ;-) Eso no es /tan/ cierto. > > Esa postura, que si bien comparto en parte, es peligrosa. Sobre todo en > > manos inexpertas que pueden creerte a ojos cerrado todo lo que dices. Claro, no es necesario comprar clusters de 10000 máquinas si un perejil abre una conexión a la base de datos cada vez que hace una consulta SQL... El rendimiento parte por varios lugares: hardware, s.o. a usar, nuestro software, nuestras conexiones a otros servidores que consumimos en la aplicacion, pero el aspecto mas manejable es el de nuestra propia algoritmia. > Si, /vivamente/ recuerdo un caso de una generacion de listados que se > demoraba horas (literalmente!), y eso /despues/ de multiplicar por 4 la > maquina seguia en las mismas; una reestructuracion de las consultas a la BD > bajo eso a cosa de un minuto. Tiempo invertido: Una media tarde... Vivo con eso... sumarle a las consultas mal hechas el que la base de datos en M$ Access no tenia ninguna relación (hasta el día de hoy estoy tratando de obtenerlas) y por si fuera poco, hay consultas que generan los resultados en otras tablas (está bien, es M$, pero como /minimo/ hacer un dataset para rellenar los controles, si estan las herramientas...) > > Eso escapa al lenguaje, escapa incluso si es compilado o interpretado. > > Y aunque las HH sean más caras, cuando esas HH te exigen aumentar el > > HW una vez al año a una potencia 4 veces mayor... Por lo demas, un programador que tenga experiencia en sistemas ya mentalmente /sabe/ los tips and tricks del lenguaje para aumentar el rendimiento. > Lamentablemente no hay ley de Moore para las HH... mas bien parece que lo > contrario :-( En la medida que avanza la tecnologia, aumenta la complejidad de los sistemas... creo que es lo bueno de .NET, que permite automatizar tonteras como logins y consultas SQL con cosas como LinQ (en PHP tambien hay ORM). Cualquier pájaro lo usa, pero... > El punto final de "mejorar rendimiento" es: > > - Es suficiente? Si es asi, OK. Salir a carretear... [Mejorar rendimiento > si ya es suficiente no tiene particular chiste...] Preocuparse excesivamente por el rendimiento, generando una suerte de paranoia, es bueno cuando se trata justamente de sitios grandes... para una aplicación de una panadería, no tiene caso. > - No es suficiente? Estudiar el problema, /a todo lo ancho/ ...y al que le toque, suerte y mis bendiciones. > - Enjuagar, repetir. Atención: No aplicar este producto directamente a los ojos. En caso de accidente lavar la zona con abundante agua y volver a revisar la documentación pertinente al sistema. > > Ojo, las mediciones hay que hacerlas con "datos reales", los "casos de > prueba" /no/ sirven, porque precisamente estan cocinados para revisar > detalladamente (incluso) lo que pasa en situaciones anomalas e > infrecuentes, mientras nos interesa un rabano el funcionamiento en casos > extraordinarios, aca nos interesan las situaciones tipicas. Depende de lo que se llame "tipico". Yo pienso (tiendo a hacerlo así, y mi respuesta está influenciada por mi trabajo actual, aunque depende del caso) que hay que pensar cada parte del sistema para "todos los casos", y probar por unidad del sistema antes de hacerlo un todo. De otra forma, se vuelve un parto. > [[Si, toda esa challa que les ensen~an /es/ importante. Desde la > organizacion general del sistema (via monitos varios) hasta llegar a su > implementacion en programas.]] monitos que pocos programadores PHP hacen, por lo visto...!!! -- Rodrigo Fuentealba Cartes Desarrollador de Sistemas Web Registered User 387639 - http://counter.li.org
