<p dir="ltr">That's not just about Haskell, it's C.S. in general.</p>
<p dir="ltr">You're always going to make space and time tradeoffs.</p>
<p dir="ltr">Funny how the same constraints appear in physics; I wonder if it is trying to tell us something...</p>
<p dir="ltr">- nitrix</p>
<div class="gmail_quote">On Jul 11, 2016 8:54 AM, "David Fox" <<a href="mailto:dsf@seereason.com">dsf@seereason.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="quoted-text"><div class="gmail_default" style="font-size:small">On Sun, Jul 10, 2016 at 11:44 AM, KC <span dir="ltr"><<a href="mailto:kc1956@gmail.com" target="_blank">kc1956@gmail.com</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><div class="quoted-text"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><p dir="ltr">Is the #functional programming paradigm antithetical to efficient strings? #Haskell</p></blockquote></div><div> ​I can certainly see how it might seem so.  Our main string representation​ uses about 10 times more memory than seems necessary, and is relatively fast, though probably not compared to C.  Recently I spent some time looking into how to reduce this memory overhead, and I modified the pretty library (<a href="https://github.com/ddssff/pretty/tree/textdetails" target="_blank">https://github.com/ddssff/pretty/tree/textdetails</a>) so it could use any type that was an instance of ListLike and StringLike (<a href="https://github.com/JohnLato/listlike" target="_blank">https://github.com/JohnLato/listlike</a>).  Then I tried the UnitLargeDoc test with several different data types.  This just concatenates a list of ten million "Hello" strings.  Using String this happens in about 5 seconds.  Using strict or lazy Text it immediately blew the stack.  When I increased the stack size to over 1GB it took minutes to complete.  When I used the Data.Text.Lazy.Builder type instead it took about 30 seconds to complete.  Results with utf8 encoded ByteStrings were siimilar.</div><div><br></div><div>When I mentioned some of this, I was told "different data structures for different purposes", which sort of makes sense, but honestly if Haskell is a language where you have to sit down and choose a representation every time you want to build some text, I get a bit discouraged.</div><div><br></div><div>So is functional programming antithetical to efficient strings?  In theory maybe not, but I would love to see some hard evidence.</div><div><br></div><div></rant></div></div></div></div>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.<br></blockquote></div>