<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
><br>
>>>2, I actually hacked yajl a bit to decode utf-8 data into the same buffer<br>
>>> it's reading from<br>
> specifically to avoid any memcpy stuff. The downside is that this<br>
> destroys the original binary term.<br>
><br>
> I wonder if that is safe on the data you get from control().  The docs don't<br>
> seem to say.   The pointer is a char* not a const char*, but that might<br>
> simply be oversight.<br>
><br>
<br>
</div>Absolutely no idea. From the stuff I read there was very little of the<br>
over view type of info that can be important.<br>
<div class="Ih2E3d"></div></blockquote><div><br>I bet there is something bad about destroying that content. This is erlnag after all, so each object should be immutable once created. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
><br>
>>>With some more hacking on yajl, it's possible that we could change around<br>
>>> the<br>
> original unicode buffer stuff to decode all unicode strings into a<br>
> single buffer and then reference that buffer etc.<br>
><br>
> Yes you could allocate a single driver binary of conservative size,<br>
> incrementally fill it with data (using sub-binary references in the<br>
> constructed term) and then realloc the binary to the final size (if it is<br>
> too large) at the end.   Good idea.    I thought I read somewhere that Yajl<br>
> will only copy strings that have unicode characters, so this method would<br>
> presumably only copy those strings.  All ascii/latin1 strings (most I would<br>
> imagine) wouldn't need to be copied (if outputv were used).<br>
><br>
</div></blockquote><div>Before implementing anything complicated I would suggest to return the data from within the originating binary if yajl didn't have to convert anything <br>(which it doesn't do if the input is UTF-8), and only in those other cases to make a new binary. The erl-driver doc says something about <br>
a BINARY_FROM_BUFFER thingy and suggests that as pretty fast. I would like to see how well that would work.<br><br><div class="Ih2E3d">
>>>I hadn't heard of EDTK prior to now, I'll take a look in the near future.<br>
><br>
> It's the Erlang Driver Toolkit. <br><br>It would b nice to have known that before :) From what I read here it seems a bit overcomplicated for what we want to achive, I would say.<br><br><br>/eno<br><br></div></div>
</div><br>-- <br>====================================================================<br>A wee piece of ruby every monday: <a href="http://1rad.wordpress.com/">http://1rad.wordpress.com/</a><br><br><br>