From: ludo@gnu.org (Ludovic Courtès)
To: guile-devel@gnu.org
Subject: Re: Add `scm_std_read ()'
Date: Mon, 21 Apr 2008 16:32:01 +0200 [thread overview]
Message-ID: <87zlrn6zz2.fsf@gnu.org> (raw)
In-Reply-To: 87k5iy4u9i.fsf@ossau.uklinux.net
Hi,
Neil Jerram <neil@ossau.uklinux.net> writes:
> I'm not sure. There are two cases which previously didn't leave and
> re-enter guile mode, and now do: (i) where there is already input
> available (fport_input_waiting), (ii) where the fd is non-blocking.
Right, good point.
> Leaving and re-entering guile mode feels quite expensive to me; it's
> at least locking and unlocking a mutex. I'm surprised that doesn't
> outweigh the gain of not calling select() a couple of times. Are you
> sure that it does?
Looking more closely at the output of the `read.bm' benchmark, we see
this (excerpt):
- Without `scm_std_read'
("read.bm: read: _IONBF" 5 total 6.69 user 1.84 system 4.84
("read.bm: read: _IOFBF 4096" 100 total 3.13 user 3.05 system 0.08
- With `scm_std_read'
("read.bm: read: _IONBF" 5 total 4.41 user 2.22 system 2.21
("read.bm: read: _IOFBF 4096" 100 total 3.11 user 3.07 system 0.05
This shows that less time is spent in the kernel, especially in the
unbuffered case (as is the case with sockets), leading to a noticeable
improvement in the unbuffered case. OTOH, part of the system overhead
is shifted to user-level in the buffered case, leading to little or no
improvement.
Conclusion: even if it's nice to improve the unbuffered case given the
current state of affairs with sockets, it probably needs some more
thought to benefit the more general case as well.
Thanks,
Ludovic.
prev parent reply other threads:[~2008-04-21 14:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-15 15:24 Add `scm_std_read ()' Ludovic Courtès
2008-04-15 22:40 ` Neil Jerram
2008-04-21 14:32 ` Ludovic Courtès [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
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zlrn6zz2.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guile-devel@gnu.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).