[erlang-questions] beam.smp startup time regression

[Tuncer Ayaz]

On Fri, Apr 4, 2014 at 5:10 PM, Björn-Egil Dahlberg <egil@REDACTED> wrote:
> 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.

Sure, I won't argue with that, but the change from +A0 to +A10 was
made in R16, so was async-threads support experimental in the past?
I'd have to check the archives, but IIRC, +A10 was made the default
for some other reason, so if it was a bad idea to run +A0, why did it
take this long for the default to change. Did everyone, including the
OTP team, always override the default?

Does that mean +Ktrue should also be the default in 18.0?

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

I totally agree.

> 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!

Good idea, but maybe we should take small steps:

1. install only .ez files
2. fix code that had assumptions

I have a feeling that there's enough stuff to fix doing that, before
we can attempt to change the unit of compilation.

If the compiler has to produce .ez files, it most probably also has to
more tightly rely on and integrate an .app file. That raises various
questions:

* how do I easily change the version of stdlib-1.2.3.ez?
  - let erlc repackage the .ez file without touching the .beam files?
* should, say, ssl-1.2.3 hard-require a precise version of stdlib?
* etc...

With that being said, I very much like the goal, and it's way overdue.
That will hopefully put to rest all the confusion why it's a good idea
(or rebar requirement) to provide .app[.src[.script]].

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

My motivation for asking, besides startup time, is that the default
has been +A0 for all those years. Therefore, I didn't assume +A0 to be
a bad choice.

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