[erlang-questions] Dialyzer startup time

[Kostis Sagonas]

Bernard Duggan wrote:
> Hi Kostis,
>     Thanks for the reply.
> 
> On 21/06/10 17:02, Kostis Sagonas wrote:
>>
>> If you are interested, give it a try and I'll help you get it working.
>> Starting from a clean system, there is a configure option:
>>
>>     --enable-native-libs
>>
>> which you should use at configuration time. Needless to mention, hipe
>> should also be enabled. Then issue a 'make'. Let us know how it works.
>>    
> Well, I've just tried that - it all compiled and built just fine, but 
> I'm still getting the "Compiling some key modules to native code" phase, 
> although now it's taking ~37s rather than ~60s (which I guess is maybe a 
> function of the compiler itself now using native code?).  Was that what 
> you were expecting, or should that step go away entirely?

Unfortunately, this step will not go away entirely (modules loaded early 
in the startup like lists will always be compiled), but you can bring it 
down considerably.

I am a bit surprised about this ~37s. Is this a very old and single core 
machine?  On my 4+ year old laptop which is single core, this step takes 
about 22s and on my 4-core office machine it's down to less than 4s (if 
you did not know it, native code compilation happens in parallel on a 
multi-core machine when SMP is enabled).

What does your Erlang banner look like?  On my office it looks as:

   Erlang R14A (erts-5.8) [source] [smp:4:4] [rq:4] ... [hipe]

which means that smp and hipe are enabled and there will be 4 Erlang 
schedulers + run queues.

Also, can you check which OTP libraries/applications were compiled to 
native code?  The ones that matter for this task are files in stdlib, 
compiler, hipe and dialyzer.

If you do not know how to look, you find out about this for some module 
by the command:

   1> [begin code:ensure_loaded(M), code:is_module_native(M) end
       || M <- [erl_types, cerl, sets, dialyzer_plt]].
   [true,true,true,true]

> Regardless, it's not a huge deal, it just seemed like something that was 
> taking a while and that might have been easy to speed up - it's not 
> going to ruin my day if I'm wrong about that :)

Yes, I understand, but it would be nice to get this working, both for 
you and for others.

Cheers,
Kostis