[Ecls-list] About the myth of slow starting

[Erik Huelsmann]

On Sat, Jun 5, 2010 at 6:50 PM, Gabriel Dos Reis
<gdr at integrable-solutions.net> wrote:
> 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 :-)

Flushing caches here does not mean an optimization: it means that the
OS should forget about any prior disc accesses. Having prior disc
access cached may (positively) influence measurements.

Bye,


Erik.