chicken-users
[Top][All Lists]
Advanced

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

Re: [Chicken-users] html-stream: idiom for large iterations?


From: Alejandro Forero Cuervo
Subject: Re: [Chicken-users] html-stream: idiom for large iterations?
Date: Mon, 2 May 2005 09:21:38 -0500
User-agent: Mutt/1.5.6+20040907i

Hello.

> Alejo, I'm curious about the performance characteristics of
> html-stream. In my (very simple  and perhaps naive) tests, the
> non-stream-based htmlprag module appears to provide much better
> performance with respect to CPU time and mutations/GC than
> html-stream.

Yes, sadly using streams of characters tends to be slow, according to
my experience (probably because it conses a lot, generating many
objects).  htmlprag writes directly to the port, which is faster.

I wonder if something could be done to make this faster...  For
instance, provide an implementation that transparently produces
streams of vectors of objects (instead of streams of objects) or even
streams of strings and see if that makes any differences.  Obviously,
this would use an interface similar to the one in SRFI-40 (say, using
‘stream*’ instead of ‘stream’) or perhaps even identical (allowing the
programmer to select which to use).  This could greatly decrease the
number of objects that the GC needs to visit.

There are cases, though, when representing strings as streams and
working on them could be much faster to other alternatives.

> Lazy evaluation is one major benefit; are there other advantages to
> "thinking in streams" that you find useful?

There are others. :)

One is that you are can implement functions that manipulate strings
with referential transparency.  I've found it makes your code much
easier to understand and maintain.  In this case you find yourself
thinking “this symbol (foo x) specifies the stream of HTML for object
x” rather than “this procedure produces/writes the stream ...”.

Also, you can implement operations that act on big inputs as if the
entire input had been read in memory.  Other approaches involve
explicitly reading things by chunks, which is cumbersome, or reading
the entire input (which makes your programs require more memory and,
if the input doesn't fit your memory, would make them extremely slow).

I've written on this before, though.  You can read *a* *draft* of a
paper on the subject at:

  
http://cgi.afc.no-ip.info/svnwiki.cgi/default/strings%20as%20streams%20in%20scheme

If you have any suggestions to improve that paper, I'd gladly hear
them.  Keep in mind that it is a draft.  :)

Thanks.

Alejo.
http://bachue.com/alejo

---=(  Comunidad de Usuarios de Software Libre en Colombia  )=---
---=(  http://bachue.com/colibri )=--=( address@hidden  )=---




reply via email to

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