9front - general discussion about 9front
 help / color / mirror / Atom feed
From: jamos@oboj.net
To: 9front@9front.org
Cc: Steve Simon <steve@quintile.net>
Subject: Re: [9front] Plan 9 buffered IO vs APE stdio in netsurf
Date: Sun, 17 May 2020 13:14:39 +0300	[thread overview]
Message-ID: <0abac8e43361c990e30aa43b0ab5f80a@oboj.net> (raw)
In-Reply-To: <B49B7A3F-A9DD-4831-B384-69C21EFA4FBE@quintile.net>

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?)


      reply	other threads:[~2020-05-17 10:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-16 10:02 jamos
2020-05-16 22:22 ` [9front] " ori
2020-05-17  9:02   ` Steve Simon
2020-05-17 10:14     ` jamos [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0abac8e43361c990e30aa43b0ab5f80a@oboj.net \
    --to=jamos@oboj.net \
    --cc=9front@9front.org \
    --cc=steve@quintile.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).