[wg-camlp4] benchmarks

[Hongbo Zhang]

On Tue, Feb 12, 2013 at 6:57 AM, Thomas Gazagnaire <thomas at ocamlpro.com>
wrote:
> Hi Hongbo,
>
>> For the user time
>> ocamlbuild cold/FanDriver.native
>> user  0m28.494s
>> ocamlbuild src/FanDriver.native
>> user  0m30.680s
>> For the system time
>> the cold directory takes
>> sys   0m3.843s
>> while the src directory takes
>> sys   0m4.657s
>
> I'm not sure to understand what you are measuring exactly here (ie. I
don't know what magic your myocamlbuild.ml is doing) and how to interpret
the results. Could you please elaborate a bit more ?

For each file subdir/a.ml in src directory, there is a corresponding file
subdir/a.ml in the cold directory, they have *the same Parsetree*, the only
difference is that file in src should be preprocessed, while the file in
cold is vanilla ocaml code that can be compiled without preprocessing.

So here
ocamlbuild src/FanDriver.native
and
ocamlbuild cold/FanDriver.native
does exactly the samething except for each file, when
compiling src/a.mo, it will compile as
ocamlc.opt -c -pp fan src/a.ml
while when compiing cold/a.ml, it works as normal
ocamlc.opt -c cold/a.ml

For our non-trivial code base, our output shows that when compiling with
preprocessing by Fan, its performance is 30s compared with 28s without
preprocessing, this means with good engineering effort, even preprocessing
as powerful as camlp4(Fan provide more features than camlp4) should bring
not too much overhead, I did some experiment before, my feeling is that
typechecking is the bottleneck in most cases.

The extra effort for Fan compared with compiling directly is a dumping
process which dumps FanAst into Parsetree, since our output is already good
enough in practice, I did not tune the GC for better performance.

>
> Cheers,
> Thomas
>
>>
>>
>> On Mon, Feb 11, 2013 at 7:20 AM, Gabriel Scherer <
gabriel.scherer at gmail.com> wrote:
>> On the other hand, build systems come and go (and ./configure is like
>> the most horrible part to add logic to in most cases), while ocamlfind
>> has proved a reliable tool as a basis for any OCaml ecosystem so far.
>> If I can shelve some logic there without making the tool more complex
>> or less elegant I think that would be better for everyone.
>>
>> On Mon, Feb 11, 2013 at 11:56 AM, Anil Madhavapeddy <anil at recoil.org>
wrote:
>> > On 11 Feb 2013, at 10:45, Gabriel Scherer <gabriel.scherer at gmail.com>
wrote:
>> >
>> >> On Mon, Feb 11, 2013 at 11:31 AM, Anil Madhavapeddy <anil at recoil.org>
wrote:
>> >>> It should work just fine with ppx, and has the advantage of reducing
the number of ocamlfind calls per-file (which is a considerable overhead on
large projects, since it has to scan the META directories on every
invocation).
>> >>
>> >> That's of course rather orthogonal to the present discussion, but have
>> >> you been in contact with Gerd to see if some caching solution would be
>> >> possible? Intuitively it feels like ocamlfind could easily maintain a
>> >> cache in /var/run/blah and only clean it on install/remove commands.
>> >>
>> >> (An external process invocation would still make some overhead so in
>> >> you're case you'd still have to go all the way, but that could improve
>> >> the threshold at which such ~hacks become interesting.)
>> >
>> > I don't think it's necessary to put this in ocamlfind, which does the
job
>> > it's designed to do very well. Just fix your build systems to run
ocamlfind
>> > at configure time, save the results, and apply them to the compiler
flags
>> > during the build phase.
>> >
>> > -anil
>> >
>> _______________________________________________
>> wg-camlp4 mailing list
>> wg-camlp4 at lists.ocaml.org
>> http://lists.ocaml.org/listinfo/wg-camlp4
>>
>>
>>
>> --
>> -- Regards, Hongbo
>> _______________________________________________
>> wg-camlp4 mailing list
>> wg-camlp4 at lists.ocaml.org
>> http://lists.ocaml.org/listinfo/wg-camlp4
>



-- 
-- Regards, Hongbo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/wg-camlp4/attachments/20130212/f4b4f8d0/attachment.html>