[erlang-questions] erlc speed (or lack thereof), Make and emake

[Björn-Egil Dahlberg]

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
> also?
>

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
foreseeable future.

On another note,
if rebar is the build-tool, what application is the concrete? A repository
search and deploy engine?

// Björn-Egil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130125/8fce85f1/attachment.htm>