diff options
| author | Björn Gustavsson <[email protected]> | 2011-11-17 20:25:48 +0100 |
|---|---|---|
| committer | Björn Gustavsson <[email protected]> | 2011-11-23 10:40:33 +0100 |
| commit | ad2962278f347a5d0341c0d5d11cbb71c83eb35b (patch) | |
| tree | 13a15497b3f109a395fbabd7aa81ceb287b10c23 /xcomp | |
| parent | b3a8ad925c72bc77d3509ef8dce155d65dc1548b (diff) | |
| download | otp-ad2962278f347a5d0341c0d5d11cbb71c83eb35b.tar.gz otp-ad2962278f347a5d0341c0d5d11cbb71c83eb35b.tar.bz2 otp-ad2962278f347a5d0341c0d5d11cbb71c83eb35b.zip | |
Avoid slow code loading of BEAM code in a hipe-enabled emulator
On my Linux computer, building the entire Erlang/OTP system
with hipe disabled took about 8 minutes. With hipe enabled,
but without any native code, the build took about 23 minutes,
i.e. more than 3 times slower. (The computer has 4 cores, and
I used 'make -j6'.)
On my eight-core Mac (running 'make -j10') there was only a slight
slowdown when hipe was enabled.
The culprit is hipe_unified_loader:post_beam_load/1, which will be
called every time a module is loaded (even if the module contains no
native code). If post_beam_load/1 is called in a hipe-enabled
emulator, it will block multi-scheduling, even if no work needs to be
done. Apparently the cost for blocking multi-scheduling can vary
greatly, depending on the operating system and system load.
As a quick and conservative fix, don't call post_beam_load/1 unless
some native code has been previously loaded.
Diffstat (limited to 'xcomp')
0 files changed, 0 insertions, 0 deletions