[erlang-questions] erlc speed (or lack thereof), Make and emake
Thu Jan 24 13:49:48 CET 2013
I'm looking for tips and tricks to use speed up compiling a bunch of
Erlang modules from within a build system that uses (gnu)Make.
The system uses Erlang, but most of it is actually C code, which is compiled
under four different compilers, plus FPGA code. So ditching 'make'
for something Erlang-centric like 'rebar' doesn't look very attractive.
Doing this on R14B03:
for 70 modules on my machine takes 39s. If I do this instead:
erlc a.erl b.erl c.erl ...
it improves to 7s. If I split the job in two parts which run at the
same time, it improves again to 4s wall time, with both cores
So, a 10x improvement in compilation speed seems attainable, but how do
I explain how to do it to 'make'?
I had a few simple ideas for fixing this, but none really work. See below.
The more complicated idea I have is to make a shell script replacement
for 'erlc' which delegates the compilation work to an Erlang node
which is already running. Seems workable, and it won't spring
surprises on 'make', e.g. -j 4 will still do the right thing.
Anyone got a neat idea?
Rest of this mail is just a list of things that don't seem to work.
Bad Idea #1: straightforward 'make'
Here's my minimal starting point for a system of three modules, a b c:
beams=(addsuffix .beam, a b c)
%.beam: %.erl nasty_global_stuff.hrl
That causes 'make' to hand one module to erlc at a time, which is slow.
Bad Idea #2: try and use just one rule for all .beams
modules=a b c
beams=$(addsuffix .beam, $(modules))
erls=$(addsuffix .erl, $(modules))
$(beams): $(erls) nasty_global_stuff.hrl
erlc $(filter %.erl, $@)
That does almost the right thing, but actually not at all. Change one
.erl and it'll recompile every .beam, because I've told 'make' that
each .beam depends on all .erl files.
Bad Idea #3: use erl -make for all Erlang compilations
That sort-of works, but it only runs one process (Erlang's own 'make'
doesn't seem to attempt running more than one compilation at a time),
passing options is not straightforward (they're not even syntactically
the same as for erlc) and it requires writing 'EMakefiles', so you
sort-of have to understand Erlang in order to be able to fiddle with
the build system.
It's also fiddly explaining dependencies between Erlang stuff and
other stuff to a combination of ordinary 'make' and erlang's own make.
--end of bad ideas---
More information about the erlang-questions