Re: Xv 3.10a-11 (i386) uploaded to master
In article <[🔎] xe14tek7plu.fsf@maneki-neko.cygnus.com> you write:
>> NO NO NO. This is why lynx, Netscape et al are taking 30 secs to start
>> up - there are so many testndisplays to do that the process stops in
>> its tracks while it sorts it out.
>Please do some profiling and convince us of that -- I don't
>particularly believe it (mostly because lynx *doens't* take that long
*sigh* 30 secs is a figure for a 486-DX33. Piranha, my machine, is a
DX4-100 and the figure is closer to 15 seconds. Here's what I sent to
Brian White on the subject.
In email I write:
> piranha:~$ time lynx
> <hits ctrl-C as soon as local server page appears>
>
> real 0m12.734s
> user 0m8.070s
> sys 0m3.430s
>
> It now takes nearly 15 secs to start lynx because for nearly every MIME
> type it has to fork a shell running /var/lib/mime/tests/testndisplay.
> It used to start up in about 1 second or so. This is not really
> acceptable - I use lynx because it is so much faster than Netscape.
> Can a more lightweight test be found, or can the test just be done once
> and the result cached for the duration of the session.
strace'ing lynx shows 80, yes EIGHTY, calls to fork(), all of which are
to call /var/lib/mime/tests/testndisplay.
>to start anyway. Of course, lynx is screwed anyway because it goes
>through the list backwards. (D'oh!)) Are you sure you don't have some
>*other* problem [testndisplay might be slow because it's not a
>builtin, but test -n $DISPLAY was practically *free* since test is
>interpreted directly by any /bin/sh we actually use...)
In email Brian White wrote:
>I've noticed the same thing in how long it takes netscape to start. I'm
>not sure where the excess overhead is coming from, though. Try the
>following commands on your system...
>time sh -c 'test -n "$DISPLAY"' ; time sh -c '/var/lib/mime/tests/testndisplay'
>The biggest discrepency I got after quite a few runs was...
> 0.100u 0.020s 0:00.16 75.0% 0+0k 0+0io 150pf+0w
> 0.120u 0.120s 0:00.45 53.3% 0+0k 0+0io 290pf+0w
>Even this, though, the real-time execution difference is less than 0.3
>seconds. The average difference was about 0.15 seconds.
Now, some basic arithmetic: 80 * 0.16 secs = 12.8 seconds, pretty close to
the delay I am seeing.
It is _NOT_ acceptable to increase a programs startup time by 15 seconds,
for no increase in functionality.
Believe me now? :-) I can post an strace output if it will help.
Jon.
Reply to: