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
> >>
> >
>