[erlang-questions] erlc speed (or lack thereof), Make and emake
Fri Jan 25 03:05:57 CET 2013
2013/1/25 Scott Lystig Fritchie <fritchie@REDACTED>
> So, almost 1.3 seconds to start up and stop. Some of that time is
> probably related to shutting down. The rest is probably startup time.
> Some fraction of that is probably the same overhead that starting "erlc"
> from scratch each time, plus some overhead that "erlc" has that "erl"
> doesn't. Reduce that sum of time, and you'll save a lot of time in your
> Makefile recipes. Plus, that reduction would likely make "escript"
> startup times lower, which would also please a lot of the Erlang world
Though we now have parallel code loading, we don't have parallel code
fetching during boot. I think most of it is dynamic on-demand fetching in a
sequential process anyways.
I think something like spec:ing what modules should be loaded in default
boot or app-file is the way to go. Start app -> batch parallel modules
loading. We want something reasonable thought through. =)
> P.S. Keeping mouth shut since rebar's automatic parallellization doesn't
> seem to interest everyone else in the thread.... :-)
rebar is awesome!
I wonder why some people seem to shy away from it?
I don't know if it is feasible to use rebar to build erlang applications
within otp. I don't think so. It would be nice to have something like that
and Emake needs a lot more attention if it would have the same role. We
don't want to make yet another make-tool. it's just silly, we have rebar.
I think if we ever manage to move out applications from otp, that we still
maintain, those should use rebar to build them. (I'm a big proponent of
splitting down the monolithic otp-repo, let's say its not really
prioritized). Within the otp-repo we will use make + erlc for the
On another note,
if rebar is the build-tool, what application is the concrete? A repository
search and deploy engine?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions