[erlang-patches] Optimization of beams string table generation

[Paul Guyot]

Le 28 juil. 2010 à 15:14, Björn Gustavsson a écrit :

> Can you give some more information about the claims in the commit
> message?
> 
> I did the following in $ERL_TOP/release/tests/stdlib_test
> (using the R14A compiler):
> 
> erlc +time -I ../test_server re_testoutput1_split_test.erl
> 
> The interesting part of the output are the following lines:
> 
> core_module                   :      10.26 s   60987.5 kB
> v3_codegen                    :       5.83 s   17908.4 kB
> beam_asm                      :       0.46 s       2.5 kB
> 
> The module contains several thousand strings
> that are used in bit syntax matching. The core_module
> and v3_codegen passes are very slow. The beam_asm
> pass is slower than usual, but fast compared to the
> slow passes.

I was not aware of +time, and found out about the slowness of beam_asm using fcover and compiling a module with several thousands of clauses like:

f(<<"binary string">>) -> atom;

With 1000 of such clauses:
lists:foreach(fun(_) -> <<I:80>> = crypto:rand_bytes(10), S = erlang:integer_to_list(I, 16), io:format("f(<<\"~s\">>) -> atom~s;\n", [S, S]) end, lists:seq(0, 1000)).

I get:
 core_module                   :       0.05 s   25922.5 kB
 v3_codegen                    :       0.09 s    6660.6 kB
 beam_asm                      :       0.28 s       2.6 kB

vs
 core_module                   :       0.06 s   20558.1 kB
 v3_codegen                    :       0.08 s    6617.9 kB
 beam_asm                      :       0.03 s       1.7 kB

with the patch (both installations are configured with --enable-native).

> Regarding the implementation, it will probably be
> faster to append new strings to the string table
> like this:
> 
> 	    NewDict = Dict#asm{strings = <<Strings/binary,StrBin/binary>>,
> 			       string_offset=NextOffset+byte_size(StrBin)},
> 
> Regarding the test case, a better place for it should be the
> compilation_SUITE module.
> 
> (The name of the test modules may not be the best, but
> compile_SUITE (mainly) tests different compiler options,
> while compilation_SUITE tests miscellanous language features.)

Do you want me to update the branch ?

Paul
-- 
Semiocast                    http://semiocast.com/
+33.175000290 - 62 bis rue Gay-Lussac, 75005 Paris