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

[Daishi Kato]

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
> this.

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

Daishi