Programar en Linux

[Rodrigo Fuentealba]

El 23/10/06, Horst H. von Brand<vonbrand en inf.utfsm.cl> escribió:
> Germán Poó Caamaño <gpoo en ubiobio.cl> wrote:
> > On Mon, 2006-10-23 at 14:00 -0300, Horst H. von Brand wrote:
> > > Juan Martínez <jeugenio en umcervantes.cl> 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