[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re: Re: [Chicken-users] performance issue in xml-rpc

From: Daishi Kato
Subject: Re: Re: Re: [Chicken-users] performance issue in xml-rpc
Date: Tue, 12 Dec 2006 13:42:01 +0900

On 12/12/06, felix winkelmann <address@hidden> wrote:
On 12/11/06, Daishi Kato <address@hidden> wrote:
> OK, did a bit.
> I'm starting to understand felix's word about chicken's slow input port.
> Just regarding with read-line, I would porpose the following:
> a) the data of tcp port includes buf, buflen, and bufindex.
> b) read-line directly accesses the buf in data for socket port.
> The questions are:
> a) can the buf can be shared by the data slot?
> b) does the socket type of the port only used with tcp.scm?

a) I don't think it gives much, really, unless you read very large
  chunks of input

Are you sure? Maybe it depends. Comparing with say, a C routine, it
could be faster than a Scheme procedure, even for a small input.

b) You mean the 'socket symbol in slot #7 of a socket structure?
  It is used in openssl, unix-sockets (and the currently unreleased
 sockets egg).

I see.
Only in openssl, not in sockets, right?

I think everything generally boils down to the one basic problem
in the I/O model currently used: every port has port "class", which
is a vector of procedures used for the possible port operations.
For input there is only read-char and peek-char. Output has a write-string
method to do bulk writes, but there is no equivalent of a read-string
method. Having just character based input kept everything quite
simple, but is probably not enough. I will try to find a solution to

Alright. I'll wait for it.
(Or I could try testing my proposal.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]