caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: skaller <skaller@users.sourceforge.net>
Cc: Caml-list List <caml-list@inria.fr>
Subject: Re: [Caml-list] Correct way of programming a CGI script
Date: Tue, 09 Oct 2007 12:26:13 +0200	[thread overview]
Message-ID: <1191925574.10162.54.camel@localhost.localdomain> (raw)
In-Reply-To: <1191879429.28011.27.camel@rosella.wigram>

Am Dienstag, den 09.10.2007, 07:37 +1000 schrieb skaller:
> On Mon, 2007-10-08 at 18:04 +0200, Gerd Stolpmann wrote:
> 
> > > I heard that OCaml is particularly slow (and probably
> > > memory-inefficient) when it comes to string manipulation.
> > 
> > No, this is nonsense. Of course, you can slow everything down by using
> > strings in an inappropriate way, like
> > 
> > let rec concat_list l =
> >   match l with
> >     [] -> ""
> >   | s :: l' -> s ^ concat_list l'
> 
> Now Gerd, I would not call the claim nonsense. If you can't
> use a data structure in a natural way, I'd say the claim indeed
> has some weight.

I don't know what the "nature" of strings is. I'm rather to believe they
are artifacts, and that there are several ways of defining strings
mostly resulting in different runtime behaviour.

The point is here that ^ always copies strings, and this is generally
expensive, especially in this example, because the same bytes are copied
every time the result string is extended.

I'm fully aware that you can get rid of this copying in the definition
of strings, but this has a price for some other operations. As said, you
can implement strings in various ways.

> If you consider an imperative loop to concat the strings
> in an array
> 
> 	let s = ref "" in
> 	for i = 0 to Array.length a do
> 		s := !s ^ a.[i]
> 	done;

I would call this version even uglier... But taste differs.

The point is that neither the O'Caml runtime representation of strings
nor the compiler (it could recognize the specific use of ^ and
implicitly convert the code so it uses a buffer) do anything for
avoiding this trap.

But we have to be fair. It is simply nonsense to call the whole O'Caml
string manipulation slow. You have access to all operations you need to
do it fast. You just have to know how to code it.

> then Ocaml is likely to do this slowly. C++ on the other
> hand will probably do this faster, especially if you reserve
> enough storage first.

> Now, back to the issue: in the Felix compiler itself, the
> code generator is printing out C++ code. This is primarily
> done with Ocaml string concatenation of exactly the kind which
> one might call 'inappropriate'. Buffer is used too, but only
> for aggregating large strings.
> 
> The reason, trivially, is that it is easier and clearer to write
> 
> 	"class " ^ name ^ " {\n" ^ 
> 	catmap "\n" string_of_member members ^
> 	"\n};\n"
> 
> 
> than to use the imperative Buffer everywhere. The above gives more
> clue to what the output looks like.

Well, if you only concatenate a few strings isn't going to be a problem,
and is probably as fast as using a buffer (which has also some cost).

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------


  parent reply	other threads:[~2007-10-09 10:26 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-08 15:08 Tom
2007-10-08 15:32 ` [Caml-list] " Dario Teixeira
2007-10-08 16:04 ` Gerd Stolpmann
2007-10-08 21:37   ` skaller
2007-10-08 22:21     ` Erik de Castro Lopo
2007-10-08 23:05       ` skaller
2007-10-08 23:19         ` skaller
2007-10-08 23:23           ` Arnaud Spiwack
2007-10-08 23:47             ` skaller
2007-10-09  5:49         ` David Teller
2007-10-09 10:15         ` Christophe TROESTLER
2007-10-09 15:29           ` skaller
2007-10-09 15:49             ` Vincent Hanquez
2007-10-09 16:00               ` Jon Harrop
2007-10-09 14:02         ` William D. Neumann
2007-10-09 15:25           ` skaller
2007-10-09 15:33             ` William D. Neumann
2007-10-09 15:48             ` Jon Harrop
2007-10-08 23:37       ` skaller
2007-10-09 10:20         ` Christophe TROESTLER
2007-10-09 13:40           ` Rope is the new string Jon Harrop
2007-10-09 15:57             ` [Caml-list] " Vincent Hanquez
2007-10-09 16:42               ` Loup Vaillant
2007-10-09 16:55                 ` Vincent Hanquez
2007-10-09 17:32                   ` Loup Vaillant
2007-10-09 19:51                     ` Vincent Hanquez
2007-10-09 21:06                       ` Loup Vaillant
2007-10-10  7:35                         ` Vincent Hanquez
2007-10-10  8:05                           ` Loup Vaillant
2007-10-11 13:23                             ` Vincent Hanquez
2007-10-09 22:04                       ` Chris King
2007-10-11 13:03                         ` Vincent Hanquez
2007-10-11 13:54                           ` skaller
2007-10-11 14:21                             ` Vincent Hanquez
2007-10-11 14:27                               ` Benjamin Monate
2007-10-11 14:48                               ` skaller
2007-10-11 21:16                                 ` Alain Frisch
2007-10-15 20:35                                 ` Warning on home-made functions dealing with UTF-8 Julien Moutinho
2007-10-15 23:51                                   ` [Caml-list] " skaller
2007-10-16  2:21                                     ` Julien Moutinho
2007-10-16 18:46                                   ` Julien Moutinho
2007-10-16 18:51                                     ` Julien Moutinho
2007-10-17  2:23                                     ` [Caml-list] " skaller
2007-10-09 10:26     ` Gerd Stolpmann [this message]
2007-10-09 15:16       ` [Caml-list] Correct way of programming a CGI script skaller
2007-10-09 15:31         ` William D. Neumann
2007-10-09 12:52     ` Brian Hurt
2007-10-09 13:56   ` Jon Harrop
2007-10-09 15:18     ` William D. Neumann
2007-10-08 16:11 ` Loup Vaillant
2007-10-08 19:07   ` Christophe TROESTLER

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1191925574.10162.54.camel@localhost.localdomain \
    --to=info@gerd-stolpmann.de \
    --cc=caml-list@inria.fr \
    --cc=skaller@users.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).