Plan 9 buffered IO vs APE stdio in netsurf

Plan 9 buffered IO vs APE stdio in netsurf

[jamos]

Folks, I have made experiments using plan 9 buffered IO (bio) for the 
logger in netsurf, in place of the standard APE stdio logging. If run in 
verbose mode (-v) directing stderr to a separate window, my time from 
start to a loaded welcome screen is down by 50% (from 2 sec to 1 sec) if 
I run locally on my laptop. If I run over my WAN link, the startup time 
is almost 10 times lower (from 6 min to 38 sec). The downside is that it 
induces changes to an otherwise working upstream file 
(nsport/netsurf/utils/log.c).

Is it worth it? I very much like bio speed, but am trying to patch the 
upstream source as little as possible.

Jonas

Re: [9front] Plan 9 buffered IO vs APE stdio in netsurf

[ori]

> Folks, I have made experiments using plan 9 buffered IO (bio) for the 
> logger in netsurf, in place of the standard APE stdio logging. If run in 
> verbose mode (-v) directing stderr to a separate window, my time from 
> start to a loaded welcome screen is down by 50% (from 2 sec to 1 sec) if 
> I run locally on my laptop. If I run over my WAN link, the startup time 
> is almost 10 times lower (from 6 min to 38 sec). The downside is that it 
> induces changes to an otherwise working upstream file 
> (nsport/netsurf/utils/log.c).
> 
> Is it worth it? I very much like bio speed, but am trying to patch the 
> upstream source as little as possible.
> 
> Jonas

It's up to you -- are you comfortable maintaining this diff against
upstream? If you are, go for it.

(The other question: why are we logging so much that this matters? Can
we shut things up, at least when not debugging?)

Re: [9front] Plan 9 buffered IO vs APE stdio in netsurf

[Steve Simon]

is bufio fundamentally a better implementation / api than stdio or are there problems with plan9’s stdio ape implementation?

one thing to try is the setbuf call in stdio - maybe if you put a big buffer (64k) on the logging file it might make stdio comperable?

just idle sunday thoughts.

-Steve


> On 17 May 2020, at 12:23 am, ori@eigenstate.org wrote:
> 
> 
>> 
>> Folks, I have made experiments using plan 9 buffered IO (bio) for the 
>> logger in netsurf, in place of the standard APE stdio logging. If run in 
>> verbose mode (-v) directing stderr to a separate window, my time from 
>> start to a loaded welcome screen is down by 50% (from 2 sec to 1 sec) if 
>> I run locally on my laptop. If I run over my WAN link, the startup time 
>> is almost 10 times lower (from 6 min to 38 sec). The downside is that it 
>> induces changes to an otherwise working upstream file 
>> (nsport/netsurf/utils/log.c).
>> 
>> Is it worth it? I very much like bio speed, but am trying to patch the 
>> upstream source as little as possible.
>> 
>> Jonas
> 
> It's up to you -- are you comfortable maintaining this diff against
> upstream? If you are, go for it.
> 
> (The other question: why are we logging so much that this matters? Can
> we shut things up, at least when not debugging?)

Re: [9front] Plan 9 buffered IO vs APE stdio in netsurf

[jamos]

Steve,

Good idea; I will experiment with setting the buffer.
I did some experiments comparing APE and native Plan 9,
and it might be that stdio printf() only buffers until
a newline (\n) as I got the following results printing
a string of 52 characters 40 times, with and without
separating the lines with newlines: (all tests where
over my WAN link) timed with time(1).

NATIVE
print() without NL 1.36r
print() with NL 1.37r
Bprint() without NL 0.14r
Bprint() with NL 0.14r

APE
printf() without NL  0.14r
printf() with NL  1.37r
Bprint() without NL 0.15r
Bprint() with NL 0.14r

(it might be that the above test was to small to
catch the real issue)

Ori,

The issue is really only while debugging, using the
verbose flag (-v) or setting the log level on the
command line [1], or the default log level in the
mkfile. I would agree that debugging of a WAN is less
important than to maintain a patch against utils/log.c.

The compiled-in log level is by default WARN, and we
get a bunch of warnings when quitting the browser, for
strings that has been allocated in libwapcaplet, but not
unreferenced. The more pages visited, the more strings,
and it seem to happen with all fetchers also for file://.
It does not happen in Linux.

I think I’ll also change the raw debugging to stderr that
we have introduced our selves, either uncommenting them,
or directing them to NSLOG(). Kyle -- is it OK to turn out/off
some debug info in webfs (for fetching pages), or do you
want them there a bit longer?

[1] 
https://ci.netsurf-browser.org/jenkins/view/Categorized/job/docs-netsurf/doxygen/md_docs_logging.html

/Jonas

On 2020-05-17 12:02, Steve Simon wrote:

> is bufio fundamentally a better implementation / api than stdio or are 
> there problems with plan9's stdio ape implementation?
> 
> one thing to try is the setbuf call in stdio - maybe if you put a big 
> buffer (64k) on the logging file it might make stdio comperable?
> 
> just idle sunday thoughts.
> 
> -Steve
> 
> On 17 May 2020, at 12:23 am, ori@eigenstate.org wrote:
> 
> Folks, I have made experiments using plan 9 buffered IO (bio) for the
> logger in netsurf, in place of the standard APE stdio logging. If run 
> in
> verbose mode (-v) directing stderr to a separate window, my time from
> start to a loaded welcome screen is down by 50% (from 2 sec to 1 sec) 
> if
> I run locally on my laptop. If I run over my WAN link, the startup time
> is almost 10 times lower (from 6 min to 38 sec). The downside is that 
> it
> induces changes to an otherwise working upstream file
> (nsport/netsurf/utils/log.c).
> 
> Is it worth it? I very much like bio speed, but am trying to patch the
> upstream source as little as possible.
> 
> Jonas
> It's up to you -- are you comfortable maintaining this diff against
> upstream? If you are, go for it.
> 
> (The other question: why are we logging so much that this matters? Can
> we shut things up, at least when not debugging?)