From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from b-painless.mh.aa.net.uk ([81.187.30.52]) by ewsd; Sun May 17 05:02:51 EDT 2020 Received: from 132.198.187.81.in-addr.arpa ([81.187.198.132] helo=quintile.net) by b-painless.mh.aa.net.uk with esmtp (Exim 4.92) (envelope-from ) id 1jaFBn-0000Jt-FE for 9front@9front.org; Sun, 17 May 2020 10:02:31 +0100 Received: from [192.168.1.37] ([81.187.198.132]) by quintile.net; Sun May 17 10:02:30 BST 2020 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Steve Simon Mime-Version: 1.0 (1.0) Subject: Re: [9front] Plan 9 buffered IO vs APE stdio in netsurf Date: Sun, 17 May 2020 10:02:29 +0100 Message-Id: References: In-Reply-To: To: 9front@9front.org X-Mailer: iPhone Mail (17E262) List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: software full-stack interface-oriented optimizer is bufio fundamentally a better implementation / api than stdio or are there= problems with plan9=E2=80=99s 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: >=20 > =EF=BB=BF >>=20 >> Folks, I have made experiments using plan 9 buffered IO (bio) for the=20 >> logger in netsurf, in place of the standard APE stdio logging. If run in=20= >> verbose mode (-v) directing stderr to a separate window, my time from=20 >> start to a loaded welcome screen is down by 50% (from 2 sec to 1 sec) if=20= >> I run locally on my laptop. If I run over my WAN link, the startup time=20= >> is almost 10 times lower (from 6 min to 38 sec). The downside is that it=20= >> induces changes to an otherwise working upstream file=20 >> (nsport/netsurf/utils/log.c). >>=20 >> Is it worth it? I very much like bio speed, but am trying to patch the=20= >> upstream source as little as possible. >>=20 >> Jonas >=20 > It's up to you -- are you comfortable maintaining this diff against > upstream? If you are, go for it. >=20 > (The other question: why are we logging so much that this matters? Can > we shut things up, at least when not debugging?)