On Fri, 16 Nov 2007, Franco Catrin L. wrote:
>
> El problema esta cuando el nivel de abstracción te oculta lo que esta
> sucediendo por debajo, y se hacen cosas demás en forma involuntaria.
> Recuerdo que Federico Mena comentaba que muchos problemas de performance se
> habian resuelto simplemente aplicando strace para ver qué estaba sucediendo
> por debajo y ahi encontraron que en aplicaciones como OpenOffice (y tambien
> en GNOME) se abrian y procesaban archivos inmutables una y otra vez, en vez
> de una sola vez al principio. Es facil tener ese problema, cuando las
> aplicaciones crecen y tienes una gran base de código te comienzas (al fin) a
> enfocar mas en el qué y no en el cómo, pero si te descuidas comienzas a mal
> usar lo que ya tienes.
>
Bueno, por ejemplo si se llama repetidamente a rutinas chicas que hacen
poco, el rendimiento se reduce en al menos un orden de magnitud en
comparacion al mismo codigo "inlined".
Es decir:
for(i=0; i<N; i++) a[i] = b[i] + c[i];
es muchisimo mas rapido que
for(i=0; i<N; i++) a[i] = sum(b[i], c[i]);
con double sum(double a, double b){ return a + b;}. Y al final muchos
codigos OO terminan haciendo cosas por el estilo (probablemente no para este
ejemplo, claro).
Saludos,
Xavier
From [EMAIL PROTECTED] Fri Nov 16 16:52:58 2007
From: [EMAIL PROTECTED] (Franco Catrin L.)
Date: Fri Nov 16 16:49:27 2007
Subject: =?utf-8?q?Re=3A_Benchmarking_en_distintos_lenguajes_=5B_Era_algo?=
=?utf-8?b?IGFzw60gY29tbyBjbGllbnRlIGVuIGphYmJlci4uLiBd?=
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Leonardo Soto M. escribió:
> On Nov 16, 2007 2:23 PM, Franco Catrin L. <[EMAIL PROTECTED]> wrote:
>
>> Rodrigo Fuentealba escribió:
>>
>>>> Hay algunas cosas que funcionan más rápido en Java pero no por un tema
>>>> de compiladores, sino que por otros aspectos como por ejemplo el
>>>> mecanismo de Garbage Collection que funciona de forma asincrona (pero no
>>>> en paralelo).
>>>>
>>>>
>>> Estuve viendo eso relacionado con Microsoft.NET; jamás se me ocurrió
>>> aplicar eso a Java. Bueeena!
>>>
>>>
>> Sumale eso a que cuando hay suficiente RAM puede funcionar muy bien.
>>
>
> Un caso práctico donde la recolección de basura podría ser mejor que
> malloc()/free() es Firefox. Análisis recientes están demostrando que
> la manía de Firefox por consumir RAM está más relacionada con
> fragmentación de memoria que "memory leaks" [1]. Y ahí un recolector
> de basura puede ayudar, compactando la memoria de vez en cuando.
>
Definitivamente ayudaría. Es curioso que esto recien se venga a detectar
(10 de nov)
Recuerdo haber visto otro análisis en donde se mostraba que las imágenes
se mantenían en memoria aunque no fueran visibles. Existen técnicas
conocidas para resolver eso, como las referencias debiles pero creo que
lo patearon para firefox 3.
Saludos
--
Franco
