In message: <20031125080155.GC76478_at_server.vk2pj.dyndns.org> Peter Jeremy <peterjeremy_at_optushome.com.au> writes: : On Mon, Nov 24, 2003 at 11:16:07PM -0700, M. Warner Losh wrote: : >Hmmmm, It looks like the hit is less than 10% in the fork intensive : >test I just wrote: : > : >#!/bin/sh : >for i in 0 1 2 3 4 5 6 7 8 9; do : > for j in 0 1 2 3 4 5 6 7 8 9; do : > for k in 0 1 2 3 4 5 6 7 8 9; do : > for l in 0 1 2 3 4 5 6 7 8 9; do : > for m in 0 1 2 3 4 5 6 7 8 9; do : > for n in 0 1 2 3 4 5 6 7 8 9; do : > true; : >done; done; done; done; done; done; : : Unless you've done something wierd to your /bin/sh, "true" is a : builtin. This test just to measures the ongoing runtime overhead : of a dynamic executable (ie PIC code). Drew's test was measuring : the startup overhead. True. However, I get very similar numbers of I change it to /usr/bin/true (12% slower). /bin/sh usually fork+exec things other /bin/sh. : >Clearly dynamic is slower, but it is more like 11% slower (10.67%) on : >the average than 40% slower. I think this would be a more typical : >usage pattern. : : You have measured different things. Drew's test shows that a dynamic : /bin/sh tahes about 40% longer to start. Your test shows that once : started, it runs about 11% slower. And the 11% slower is _very_ : worrying since it is probably more widely applicable than just /bin/sh. Dynamically linked prorgrams tend to be a few percent slower than their static counterparts due to PIC code typically being slower than non-PIC code. There's nothing new here. Clearly there are problems to look into, but it isn't the end of the world. WarnerReceived on Mon Nov 24 2003 - 23:17:57 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:30 UTC