[erlang-questions] beam.smp startup time regression

[Björn-Egil Dahlberg]

Async threads are there for a reason. If your threads (schedulers hangs 
on files - nfs for instance) you are in big trouble, time will not 
progress in the system - hence the async threads. This has been 
reiterated many times on this list.

I think the better solution would be to use archives instead, fewer 
files to load and hence fewer file access latency overheads. I believe 
this would help the startup time greatly.

So why don't we have archives right now .. well modules works fine and 
there hasn't been a great need for archives. Ideally applications should 
be compiled to archives directly and loaded as an application entity, 
not as modules. This would have other implications as well .. such as we 
could allow inlining between modules within the same application. 
Holistically, application entities would be great!

For escript +A0 might work in some cases but I would not recommend it. 
In most cases it would probably seem like it works fine though.

// Björn-Egil

On 2014-04-04 16:49, Tuncer Ayaz wrote:
> In addition to "erl -eval 'halt(0).'", I tried "rebar --version", and
> the results (ignoring extreme outliers) with R16B03-1 +A0 are
> promising.
>
> $ time rebar --version
> low:
> real    0m0.280s
> user    0m0.240s
> sys     0m0.053s
>
> high:
> real    0m0.375s
> user    0m0.313s
> sys     0m0.063s
>
> $ export ERL_FLAGS=+A0
> $ time rebar --version
> low:
> real    0m0.244s
> user    0m0.200s
> sys     0m0.037s
>
> high:
> real    0m0.262s
> user    0m0.217s
> sys     0m0.033s
>
> Egil, would you advise against adding +A0 to rebar's escript emu_args
> in the header? I mean, is it generally important to have async threads
> for any kind of erlang code running on R16 and later?
>
>