From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 25ACFBBAF for ; Mon, 23 Aug 2010 03:02:34 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwCAOhlcUzRVdivkGdsb2JhbACScYU7h3gIFQEBAQEJCQwHEQMfnh+ZR4U3BIFWgl+FQQ X-IronPort-AV: E=Sophos;i="4.56,254,1280700000"; d="scan'208";a="65979486" Received: from mail-qy0-f175.google.com ([209.85.216.175]) by mail1-smtp-roc.national.inria.fr with ESMTP; 23 Aug 2010 03:02:26 +0200 Received: by qyk8 with SMTP id 8so2383870qyk.6 for ; Sun, 22 Aug 2010 18:02:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.54.69 with SMTP id p5mr2833544qag.264.1282525345488; Sun, 22 Aug 2010 18:02:25 -0700 (PDT) Received: by 10.229.97.81 with HTTP; Sun, 22 Aug 2010 18:02:25 -0700 (PDT) X-Originating-IP: [99.180.100.231] In-Reply-To: References: <1282434367.988.11.camel@mathias-ens> Date: Sun, 22 Aug 2010 20:02:25 -0500 Message-ID: Subject: Re: [Caml-list] caml_copy_string From: Jeffrey Barber To: Till Varoquaux Cc: Mathias Kende , caml-list@inria.fr Content-Type: multipart/alternative; boundary=0015175cdee2a22071048e73338a X-Spam: no; 0.00; node:01 ocaml:01 alloc:01 allocator:01 alloc:01 buffer:01 ocaml:01 memcpy:01 malloc:01 byterun:01 mlvalues:01 val:01 val:01 ffi:01 byte:01 --0015175cdee2a22071048e73338a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 buffe= r strings and make a separate read_line that uses caml_alloc. On Sun, Aug 22, 2010 at 7:42 PM, Till Varoquaux 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 > 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 > wrote: > >> Le samedi 21 ao=FBt 2010 =E0 18:30 -0500, Jeffrey Barber a =E9crit : > >>> 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 yoursel= f > >> but then the string must have been specially allocated because you nee= d > >> 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 w= ay > >> is to always allocate them with the caml_alloc_string function. That w= ay > >> 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 t= he > >> 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 > >> > > > --0015175cdee2a22071048e73338a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable No known bottlenecks yet, just making a list of possible bottlenecks so I c= an sleep on ways of optimizing them when I get node.ocaml to "feature = complete" status.

For this issue, I'm going to use Mathias&= #39;s advice for caml_alloc_string and try two things. I'm going to tes= t giving libevent a custom memory allocator that uses caml_alloc_string, an= d the other way is just focus on how I buffer strings and make a separate r= ead_line that uses caml_alloc.

On Sun, Aug 22, 2010 at 7:42 PM, Till Varoqu= aux <till@pps.j= ussieu.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 =A0sure 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=FBt 2010 =E0 18:30 -0500, Jeffrey Barber a =E9crit= :
>>> 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 stri= ng?
>>
>> There is no such function in the Caml FFI. You could write one you= rself
>> 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 easie= st way
>> is to always allocate them with the caml_alloc_string function. Th= at 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-li= st
>> Archives: http:= //caml.inria.fr
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginner= s
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>>
>

--0015175cdee2a22071048e73338a--