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 <t...@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 <t...@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.ke...@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 > >> > > >
_______________________________________________ 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
