Otto Moerbeek wrote:
>It is not a problem of crashing or not, S does incur a performance hit
>that we are not willing accept by default.
I've seen this claim several times on this mailing list over the past
few years but does anyone have actual data about it? How much of a
performance hit is it in practice for, say, some typical tasks
(whatever "typical" means)? I'm asking because I've been using S on
my 10 year old laptop for 2.5 years now and I don't remember seeing any
noticeable difference (or am I just very tolerant of low performance?)
Out of curiosity, here's the result of running "time /bin/sh
/etc/daily" three times in a row with /etc/malloc.conf -> S:
5m37.69s real 0m48.49s user 0m44.67s system
5m17.96s real 0m48.06s user 0m41.99s system
5m21.30s real 0m49.89s user 0m43.91s system
(the faster second and third results are probably due to caching effects)
and with no /etc/malloc.conf:
5m04.51s real 0m45.32s user 0m30.61s system
5m07.56s real 0m46.62s user 0m31.22s system
5m05.88s real 0m45.81s user 0m30.47s system
So it's a performance hit of about 15 seconds out of more than five
minutes, so about 5%. Not great but not something that a human would
be likely to notice without actually timing it. Granted, /etc/daily
might not be a perfect example because it seems to be mainly I/O bound
(and my computer is not really representative of today's machines
anyway), but I'd guess that a CPU bound program would probably
allocate memory up front and have a low hit in the long run, while a
memory intensive program (say, a language interpreter) would probably
have its own GC system making the speed of malloc not so much of a
problem. Does anyone know of a relatively common program for which S
is a human-noticeable performance hit?
Cheers,
Philippe
