On 6/1/07, David MENTRE <dmentre@linux-france.org> wrote:
> 2007/6/1, Yaron Minsky <yminsky@cs.cornell.edu>:
> > In other words,
> > factoring out with functors and modules is good style, but OCaml penalizes
> > you for it.
>
> A naive and somewhat provocative question: is the performance penalty
> a real issue in your production code or just a known overhead that is
> easily solved by having a more powerful computer? In other words, is
> the complexity price of better optimizations justified considering its
> real impact in production code?

Absolutely!  E.g. we had to specialize hash tables for integer and
string keys, because the generic implementation calls a function for
each key comparison rather than generating specialized code for e.g.
integer comparisons.  This has a noticable impact in production
systems.

There are plenty of cases where I had to manually unfold function
definitions like e.g.:

  let f = g h

where h is some function.  This leads to a lot of code duplication,
and makes code considerably less readable (though a lot more efficient
if e.g. h is applied to each character in a string).

I'd surely be happy to see the addition of some (optional)
higher-level code transformations to OCaml.  Not just inlining, maybe
some partial evaluation of the resulting code, which could also reduce
code size if the compiler can prove that certain branches will not be
taken.

Regards,
Markus

-- 
Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com