[erlang-questions] Why is erlc so quick to start?
Tuncer Ayaz
tuncer.ayaz@REDACTED
Fri Jan 9 19:16:46 CET 2015
On Tue, Jan 6, 2015 at 11:43 AM, Loic Hoguin wrote:
> On 01/06/2015 11:13 AM, Tuncer Ayaz wrote:
> >
> > On Tue, Jan 6, 2015 at 12:06 AM, Loic Hoguin wrote:
> > >
> > > Yes that also adds to the load time, but it probably wouldn't be
> > > too noticeable if erlc was loading only the modules it requires
> > > instead of everything. I don't think it uses the network code,
> > > dets, process
> >
> >
> > It can use the network code if code is not loaded from disk.
> > Erlang's distributed nature is the reason for some indirection you
> > tried to circumvent in, for example, file operations :).
>
>
> But erlc only compiles *files* doesn't it? It doesn't start
> distribution or anything so there should be no indirection?
I was referring to the fact that erl_prim_loader can use either efile
or inet as the loader, and that this might pull in more modules.
> > > groups and so on, and it may also not need the whole OTP
> > > application framework.
> > >
> > > I will play with generating a smaller boot file when I get the
> > > time and see what happens. If it can be made closer to 0s this
> > > would allow me to just use %.erl: %.beam rules, something that's
> > > been on my wishlist from the start.
> >
> >
> > Maybe the resulting boot file can be used for escript as well.
>
>
> Well "escript" wouldn't be part of the boot file if erlc doesn't
> need it, so my guess is no. :-)
Given that you're using erl_compile.beam, I wouldn't expect too much
more to add for getting escript running, so if you document the
process, we can try the same for escript and maybe make escript use a
custom boot file.
> The hard part is figuring out what it actually needs.
>
> > Also, the speedups we've discussed also apply to older versions
> > and are not fixing the overhead introduced between R13 and now.
> > So, if you're serious about this, and want to invest time, I'd
> > suggest to profile R13 against R14 and R15 with your trace/profile
> > tool of choice and see where time in (mostly) C and maybe Erlang
> > is spent since >=R14.
>
>
> I wish I could invest time now but this and the boot file experiment
> will probably have to wait for a while.
Maybe we should add a page on erlang.org or the github wiki with
interesting projects for people who are actively looking for
challenges to get into otp.git. Bruce?
More information about the erlang-questions
mailing list