[Ecls-list] About the myth of slow starting

Gabriel Dos Reis gdr at integrable-solutions.net
Sat Jun 5 16:50:43 UTC 2010

On Sat, Jun 5, 2010 at 11:45 AM, Stas Boukarev <stassats at gmail.com> wrote:
> Gabriel Dos Reis <gdr at integrable-solutions.net> writes:
>> On Sat, Jun 5, 2010 at 10:34 AM, Juan Jose Garcia-Ripoll
>> <juanjose.garciaripoll at googlemail.com> wrote:
>>> On Sat, Jun 5, 2010 at 5:26 PM, Stas Boukarev <stassats at gmail.com> wrote:
>>>> > https://sourceforge.net/news/?group_id=30035&id=287636
>>>> SBCL has quite a large core, so unless it's cached by FS loading it
>>>> isn't so fast.
>>>> With caches dropped (echo 3 > /proc/sys/vm/drop_caches) ECL is actually
>>>>  faster than SBCL at start.
>>> Indeed, this is normally my experience in OS X, but I did not want to offer
>>> the "best" or "biased" numbers. Instead I just took a system where SBCL has
>>> to perform well (Linux) and ECL does not do so bad.
>> I agree with that:  many interested ECL users do not have the luxury of fiddling
>> around with the kernel parameters.  So, the normal conditions of good ECL
>> performance should not require that -- and I applaud that view.
> That's not a kernel parameter, that's just a way to flush caches,

whatever you call it :-)

> otherwise timing would be hard. But you will get the same numbers when
> you first start ECL or SBCL.

Imagine a multi-user environment -- which isn't uncommon, even these
days where many people have their own laptops.

dromion[11:48]% ls -ld /proc/sys/vm/drop_caches
-rw-r--r-- 1 root root 0 2010-06-05 11:48 /proc/sys/vm/drop_caches

The point is: not everybody gets the luxury with fiddling with the system.
And good ECL performance should not require that.

-- Gaby

More information about the ecl-devel mailing list