On Wed, Nov 23, 2016 at 06:55:52AM -0500, Philippe Meunier wrote:
> 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
Your assumptions on on memoryb intensive applications doing smart
thing re memory is not true in general.
If you look at the actual user and system time in the daily runs,
you'll see that usertime + systemtime goes from about 77s to 90s.
About 16% more cycles are used when S is active.
I think that's enough evidence to see that S has a real performeace inpact.
Another test (I have C in /etc/malloc.conf so I need to switch it off
explicitly) is e.g. building. This we do a lot as developers. On a
fast machine with SSD this is CPU bound:
$ pwd
/usr/src/bin/ksh
$ MALLOC_OPTIONS=c time make
5.50 real 4.63 user 0.89 sys
$ make clean
$ MALLOC_OPTIONS=S time make
9.28 real 5.40 user 3.94 sys
Here the difference is even bigger (about 68%). I think that shows
enough why S isn't the default (apart from buggy third party
software).
-Otto
