[web-devel] Re: [Haskell-cafe] Google Summer of Code: BlazeHTML RFC

[Michael Snoyman]

On Thu, May 27, 2010 at 11:28 AM, Ivan Miljenovic <ivan.miljenovic at gmail.com
> wrote:

> On 27 May 2010 18:23, Michael Snoyman <michael at snoyman.com> wrote:
> >
> >
> > On Thu, May 27, 2010 at 11:16 AM, Ivan Miljenovic
> > <ivan.miljenovic at gmail.com> wrote:
> >>
> >> On 27 May 2010 17:55, Michael Snoyman <michael at snoyman.com> wrote:
> >> > Two comments:
> >> > * The exclamation point seems good enough for attributes. I copied
> that
> >> > for
> >> > Hamlet as well.
> >> > * If you're standardizing on UTF-8, why not support bytestrings? I'm
> >> > aware
> >> > that a user could shoot him/herself in the foot by passing in non-UTF8
> >> > data,
> >> > but I would imagine the performance gains would outweigh this. My
> recent
> >> > benchmarks on the BigTable benchmark[1] imply a huge performance gap
> >> > between
> >> > ByteStrings and other contenders.
> >>
> >> Wow, I find it rather surprising that String out-performs Text; any
> >> idea why that is?  I wonder if you're just using it wrong...
> >>
> > Could be, I'd be very happy if that were the case. All of the benchmarks
> are
> > available on Github, and the bytestring[1], text[2] and string[3]
> versions
> > are all rather short.
>
> Does using lazy Text values improve this?  I find it a little strange
> that you concatenate so many individual Strings that much.  Also, how
> about explicitly using Text values rather than OverloadedStrings?
>
> I don't do any string concatenation (look closely), I was very careful to
avoid it. I tried with lazy text as well: it was slower. This isn't
surprising, since lazy text- under the surface- is just a list of strict
text. And the benchmark itself already has a lazy list of strict text. Using
lazy text would just be adding a layer of wrapping.

I don't know what you mean by "explicitly using Text values"; you mean
calling pack manually? That's really all that OverloadedStrings does.

You can try out lots of different variants on that benchmark. I did that
already, and found this to be the fastest version.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/web-devel/attachments/20100527/a9541240/attachment.html