No known bottlenecks yet, just making a list of possible bottlenecks so I can sleep on ways of optimizing them when I get node.ocaml to "feature complete" status.

For this issue, I'm going to use Mathias's advice for caml_alloc_string and try two things. I'm going to test giving libevent a custom memory allocator that uses caml_alloc_string, and the other way is just focus on how I buffer strings and make a separate read_line that uses caml_alloc.

On Sun, Aug 22, 2010 at 7:42 PM, Till Varoquaux <till@pps.jussieu.fr> wrote:
Actually Mathias is spot on: you need your string to be allocated in
the memory region owned by the ocaml GC and tagged properly (that is
wrapped with the correct GC info). After that you can pass it around
in C as a string but you should never resize it. That being said you
only save a call to what existentially is memcpy (unless you need to
malloc your c string): this should be real fast. Are you  sure this is
your bottleneck?

Till

On Sun, Aug 22, 2010 at 1:16 PM, Till Varoquaux <till@pps.jussieu.fr> wrote:
> In byterun/mlvalues.h
>
> #define Bp_val(v) ((char *) (v))
> ....
> #define String_val(x) ((char *) Bp_val(x))
>
> Doesn't look like String_val is doing much copying to me....
>
>
> Till
>
> On Sat, Aug 21, 2010 at 7:46 PM, Mathias Kende <mathias.kende@ens.fr> wrote:
>> Le samedi 21 août 2010 à 18:30 -0500, Jeffrey Barber a écrit :
>>> Is there a way to get a string from C to OCaml without the
>>> caml_copy_string
>>> function, or is there a version that doesn't copy the string?
>>
>> There is no such function in the Caml FFI. You could write one yourself
>> but then the string must have been specially allocated because you need
>> to add a one word header to the string and maybe some byte at the end.
>> So, if you have to exchange strings between OCaml and C, the easiest way
>> is to always allocate them with the caml_alloc_string function. That way
>> you can use the pointer returned by String_val in your C code and the
>> string remains a valid Caml string (except caml does not use zero as the
>> end of string and will stick to its allocated size).
>>
>> Mathias
>>
>> _______________________________________________
>> Caml-list mailing list. Subscription management:
>> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
>> Archives: http://caml.inria.fr
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>>
>