<br><br>On Tue, Feb 12, 2013 at 6:57 AM, Thomas Gazagnaire <<a href="mailto:thomas@ocamlpro.com">thomas@ocamlpro.com</a>> wrote:<br>> Hi Hongbo,<br>><br>>> For the user time<br>>> ocamlbuild cold/FanDriver.native<br>
>> user  0m28.494s<br>>> ocamlbuild src/FanDriver.native<br>>> user  0m30.680s<br>>> For the system time<br>>> the cold directory takes<br>>> sys   0m3.843s<br>>> while the src directory takes<br>
>> sys   0m4.657s<br>><br>> I'm not sure to understand what you are measuring exactly here (ie. I don't know what magic your <a href="http://myocamlbuild.ml">myocamlbuild.ml</a> is doing) and how to interpret the results. Could you please elaborate a bit more ?<br>
<br>For each file subdir/<a href="http://a.ml">a.ml</a> in src directory, there is a corresponding file subdir/<a href="http://a.ml">a.ml</a> in the cold directory, they have <b>the same Parsetree</b>, 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.<br>
<br>So here <br>ocamlbuild src/FanDriver.native <br>and<br>ocamlbuild cold/FanDriver.native<br>does exactly the samething except for each file, when <br>compiling src/a.mo, it will compile as<br>ocamlc.opt -c -pp fan src/<a href="http://a.ml">a.ml</a> <br>
while when compiing cold/<a href="http://a.ml">a.ml</a>, it works as normal<br>ocamlc.opt -c cold/<a href="http://a.ml">a.ml</a><br> <div>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.</div>
<div><br></div><div>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.</div>
<div><br>><br>> Cheers,<br>> Thomas<br>><br>>><br>>><br>>> On Mon, Feb 11, 2013 at 7:20 AM, Gabriel Scherer <<a href="mailto:gabriel.scherer@gmail.com">gabriel.scherer@gmail.com</a>> wrote:<br>
>> On the other hand, build systems come and go (and ./configure is like<br>>> the most horrible part to add logic to in most cases), while ocamlfind<br>>> has proved a reliable tool as a basis for any OCaml ecosystem so far.<br>
>> If I can shelve some logic there without making the tool more complex<br>>> or less elegant I think that would be better for everyone.<br>>><br>>> On Mon, Feb 11, 2013 at 11:56 AM, Anil Madhavapeddy <<a href="mailto:anil@recoil.org">anil@recoil.org</a>> wrote:<br>
>> > On 11 Feb 2013, at 10:45, Gabriel Scherer <<a href="mailto:gabriel.scherer@gmail.com">gabriel.scherer@gmail.com</a>> wrote:<br>>> ><br>>> >> On Mon, Feb 11, 2013 at 11:31 AM, Anil Madhavapeddy <<a href="mailto:anil@recoil.org">anil@recoil.org</a>> wrote:<br>
>> >>> 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).<br>
>> >><br>>> >> That's of course rather orthogonal to the present discussion, but have<br>>> >> you been in contact with Gerd to see if some caching solution would be<br>>> >> possible? Intuitively it feels like ocamlfind could easily maintain a<br>
>> >> cache in /var/run/blah and only clean it on install/remove commands.<br>>> >><br>>> >> (An external process invocation would still make some overhead so in<br>>> >> you're case you'd still have to go all the way, but that could improve<br>
>> >> the threshold at which such ~hacks become interesting.)<br>>> ><br>>> > I don't think it's necessary to put this in ocamlfind, which does the job<br>>> > it's designed to do very well. Just fix your build systems to run ocamlfind<br>
>> > at configure time, save the results, and apply them to the compiler flags<br>>> > during the build phase.<br>>> ><br>>> > -anil<br>>> ><br>>> _______________________________________________<br>
>> wg-camlp4 mailing list<br>>> <a href="mailto:wg-camlp4@lists.ocaml.org">wg-camlp4@lists.ocaml.org</a><br>>> <a href="http://lists.ocaml.org/listinfo/wg-camlp4">http://lists.ocaml.org/listinfo/wg-camlp4</a><br>
>><br>>><br>>><br>>> --<br>>> -- Regards, Hongbo<br>>> _______________________________________________<br>>> wg-camlp4 mailing list<br>>> <a href="mailto:wg-camlp4@lists.ocaml.org">wg-camlp4@lists.ocaml.org</a><br>
>> <a href="http://lists.ocaml.org/listinfo/wg-camlp4">http://lists.ocaml.org/listinfo/wg-camlp4</a><br>><br><br><br><br>-- <br>-- Regards, Hongbo<br></div>