From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 314907FA13 for ; Thu, 10 Jul 2014 08:41:33 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of nicolas.boulay@gmail.com) identity=pra; client-ip=209.85.213.172; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="nicolas.boulay@gmail.com"; x-sender="nicolas.boulay@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of nicolas.boulay@gmail.com designates 209.85.213.172 as permitted sender) identity=mailfrom; client-ip=209.85.213.172; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="nicolas.boulay@gmail.com"; x-sender="nicolas.boulay@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ig0-f172.google.com) identity=helo; client-ip=209.85.213.172; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="nicolas.boulay@gmail.com"; x-sender="postmaster@mail-ig0-f172.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIBAA81vlPRVdWsm2dsb2JhbABZg2Bagm+8ModqWQgWDwEBAQEBBgsLCRQohAMBAQEDARIRHQEUJAEDAQsBBQMCCw0qAgIiEgEFARwZCAELBweIDAMJCA2SDpAWaosnhQKMcScNhwMRAQUOkjIPgT0FmHuBfZIdGCmBaoMLOy8 X-IPAS-Result: AjIBAA81vlPRVdWsm2dsb2JhbABZg2Bagm+8ModqWQgWDwEBAQEBBgsLCRQohAMBAQEDARIRHQEUJAEDAQsBBQMCCw0qAgIiEgEFARwZCAELBweIDAMJCA2SDpAWaosnhQKMcScNhwMRAQUOkjIPgT0FmHuBfZIdGCmBaoMLOy8 X-IronPort-AV: E=Sophos;i="5.01,636,1400018400"; d="scan'208";a="70807204" Received: from mail-ig0-f172.google.com ([209.85.213.172]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 10 Jul 2014 08:41:31 +0200 Received: by mail-ig0-f172.google.com with SMTP id hn18so2745248igb.5 for ; Wed, 09 Jul 2014 23:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:cc:content-type; bh=bdnsOx0b0fNnZJlGx97gESFvS2HcxtNvEyfvctnFyus=; b=J3vKWSlidWad/p7+SJDMi2Hh8fUYUc9ZZRwNAiZ6PsfgJidJjA/NebpDxmhiVD9fKt 5wrV7d+jxVvg1Iy9HNKHbKatYET4a3qgdZ1El0NFDFnOCJYyfn885c4QoPCerm2V7B4s vKY4cTRm4S4fO8nTEnlabs/30KQ0xv239WTo+ZFpXgwKTtW1umeV8Tjule5t/nUN8RfK vUDrmaxLzb2Y5CaBxdtjPzZHISLUQNzzOPCeHU350n+t9Wk2mcRAU/KjF0UriuYxoCTf 0FA3YpNFr0YtABqELlvpO4hXEaev3VuS3YKwWRxAvdrWE7qMYg+JRyWE61ug7uCWmYI8 UOcw== MIME-Version: 1.0 X-Received: by 10.43.7.10 with SMTP id om10mr28654840icb.66.1404974490466; Wed, 09 Jul 2014 23:41:30 -0700 (PDT) Sender: nicolas.boulay@gmail.com Received: by 10.50.73.131 with HTTP; Wed, 9 Jul 2014 23:41:30 -0700 (PDT) In-Reply-To: <1404929044.4384.159.camel@e130> References: <1404501528.4384.4.camel@e130> <53BA95AC.3050602@frisch.fr> <1404822242.4384.101.camel@e130> <53BD49B1.6000203@frisch.fr> <1404929044.4384.159.camel@e130> Date: Thu, 10 Jul 2014 08:41:30 +0200 X-Google-Sender-Auth: ylX2q8nlp-UMbscW3KsHKKEZm1Q Message-ID: From: Nicolas Boulay Cc: caml-list Content-Type: multipart/alternative; boundary=bcaec5101c0f6c3e5c04fdd11d4c X-Validation-by: nicolas@boulay.name Subject: Re: [Caml-list] Immutable strings --bcaec5101c0f6c3e5c04fdd11d4c Content-Type: text/plain; charset=UTF-8 In one of my program, i parse lot of small files. Most of the time was consume by the GC, because lot of string was created. File are read into string then converted to data structure, but those string buffer are not easly reusable for the next file. So the GC have a hard work. Maybe ocaml need a way to enable the reuse of string to reduce the pressure on the GC, and reduce the need of mutable string. Regards, Nicolas 2014-07-09 20:04 GMT+02:00 Gerd Stolpmann : > Am Mittwoch, den 09.07.2014, 15:54 +0200 schrieb Alain Frisch: > > On 07/08/2014 02:24 PM, Gerd Stolpmann wrote: > > > It will create confusion even with actively maintained code bases. What > > > could help here is very clear communication when the change will be the > > > standard behavior, and how the migration will take place. > > > > It's a very different kind of criticism from your initial point about > > the decision of going into the current direction. > > Right, but the question how the user process will look like is just the > next one. The design of the change so far is minimalistic, and it is > obvious that some abstraction is missing, and my only explanation is > that there wasn't a consensus in the OCaml team (but that's just a wild > guess). I don't want to say that the OCaml team is ignoring any > problems, but it looks like the missing abstraction is somehow offloaded > to the users, namely whether it is needed at all in the stdlib (maybe > nobody is complaining), or which style is preferred. (I just want to say > that there is IMHO a connection between the minimalistic design, and the > social embedding.) > > > Point taken: the > > development team will need to communicate about the expected timeline > > and migrate path. But note that 4.02 is not even out, and since the > > default behavior is the previous one, there is no hurry, and it's fine > > if people wait a few months before trying the new mode. > > My thinking here is that 95% of the users will have no problems at all > when they convert their programs. It's the other 5% for which the > current design is not really sufficient. Let's just hope these users > aren't immediately discouraged when they find it out. > > > It doesn't > > seem crazy to wait for some early user feedback and synchronize with > > them before deciding on a more precise plan for the wider community. For > > instance, you feedback about porting ocamlnet is quite useful and the > > current discussion shows that several solutions compete and need further > > thought. Without the new compiler switch, this discussion would not > > have taken place. > > Fully agreed. > > > > I think it would be quite important to have that in the stdlib: > > > > > > - This sets a standard for interoperability between libraries > > > - The stdlib can exploit the details of the representation > > > - It would be possible to use stringlike directly in C interfaces > > > > Note that if it goes to stdlib, one cannot refer to bigarrays. (One > > might want to have bigarrays in stdlib, but we are not there yet.) > > Right, but this isn't a big deal. (Bigarray also uses Unix.file_descr, > but this dep is easy to work around by anchoring file_descr in > Pervasives.) > > > Gerd > -- > ------------------------------------------------------------ > Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de > My OCaml site: http://www.camlcity.org > Contact details: http://www.camlcity.org/contact.html > Company homepage: http://www.gerd-stolpmann.de > ------------------------------------------------------------ > > --bcaec5101c0f6c3e5c04fdd11d4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In one of my program, i parse lot of small files= . Most of the time was consume by the GC, because lot of string was created= . File are read into string then converted to data structure, but those str= ing buffer are not easly reusable for the next file. So the GC have a hard = work.

Maybe ocaml need a way to enable the reuse of string to reduce the pres= sure on the GC, and reduce the need of mutable string.

Regards= ,
Nicolas


2014-07-09 20:04 GMT+02:00 Gerd Stolpmann <info@gerd-stolpmann.de= >:
Am Mittwoch, den 09.07.2014, 15:54 +0200 schrieb Alain Frisch:
> On 07/08/2014 02:24 PM, Gerd Stolpmann wrote:
> > It will create confusion even with actively maintained code bases= . What
> > could help here is very clear communication when the change will = be the
> > standard behavior, and how the migration will take place.
>
> It's a very different kind of criticism from your initial point ab= out
> the decision of going into the current direction.

Right, but the question how the user process will look like is just t= he
next one. The design of the change so far is minimalistic, and it is
obvious that some abstraction is missing, and my only explanation is
that there wasn't a consensus in the OCaml team (but that's just a = wild
guess). I don't want to say that the OCaml team is ignoring any
problems, but it looks like the missing abstraction is somehow offloaded
to the users, namely whether it is needed at all in the stdlib (maybe
nobody is complaining), or which style is preferred. (I just want to say
that there is IMHO a connection between the minimalistic design, and the
social embedding.)

> =C2=A0 Point taken: the
> development team will need to communicate about the expected timeline<= br> > and migrate path. =C2=A0But note that 4.02 is not even out, and since = the
> default behavior is the previous one, there is no hurry, and it's = fine
> if people wait a few months before trying the new mode.

My thinking here is that 95% of the users will have no problems at al= l
when they convert their programs. It's the other 5% for which the
current design is not really sufficient. Let's just hope these users
aren't immediately discouraged when they find it out.

> =C2=A0 =C2=A0It doesn't
> seem crazy to wait for some early user feedback and synchronize with > them before deciding on a more precise plan for the wider community. F= or
> instance, you feedback about porting ocamlnet is quite useful and the<= br> > current discussion shows that several solutions compete and need furth= er
> thought. =C2=A0Without the new compiler switch, this discussion would = not
> have taken place.

Fully agreed.

> > I think it would be quite important to have that in the stdlib: > >
> > =C2=A0 - This sets a standard for interoperability between librar= ies
> > =C2=A0 - The stdlib can exploit the details of the representation=
> > =C2=A0 - It would be possible to use stringlike directly in C int= erfaces
>
> Note that if it goes to stdlib, one cannot refer to bigarrays. =C2=A0(= One
> might want to have bigarrays in stdlib, but we are not there yet.)

Right, but this isn't a big deal. (Bigarray also uses Unix.file_d= escr,
but this dep is easy to work around by anchoring file_descr in
Pervasives.)


Gerd
--
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany =C2=A0 =C2=A0gerd@gerd-stolpmann.de
My OCaml site: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.camlcity.org
Contact details: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.camlcity.org/contact.html
Company homepage: =C2=A0 =C2=A0 =C2=A0 http://www.gerd-stolpmann.de
------------------------------------------------------------


--bcaec5101c0f6c3e5c04fdd11d4c--