aboutsummaryrefslogtreecommitdiffstats
path: root/erts/emulator/test/multi_load_SUITE.erl
AgeCommit message (Collapse)Author
2016-04-13Merge branch 'henrik/update-copyrightyear'Henrik Nord
* henrik/update-copyrightyear: update copyright-year
2016-04-08Remove unnecessary ct boilerplate in suiteBjörn-Egil Dahlberg
2016-04-08Don't divide by zero in test loggingBjörn-Egil Dahlberg
2016-03-15update copyright-yearHenrik Nord
2016-02-25Add has_prepared_code_on_load/1 BIFBjörn Gustavsson
2016-02-25Allow erlang:finish_loading/1 to load more than one moduleBjörn Gustavsson
The BIFs prepare_loading/2 and finish_loading/1 have been designed to allow fast loading in parallel of many modules. Because of the complications with on_load functions, the initial implementation of finish_loading/1 only allowed a single element in the list of prepared modules. finish_loading/1 does not suspend other processes, but it must wait for all schedulers to pass a write barrier ("thread progress"). The time for all schedulers to pass the write barrier is highly variable, depending on what kind of code they are executing. Therefore, allowing finish_loading/1 to finish the loading for more than one module before passing the write barrier could potentially be much faster than calling finish_loading/1 multiple times. The test case many/1 run on my computer shows that with "heavy load", finish loading of 100 modules in parallel is almost 50 times faster than loading them sequentially. With "light load", the gain is still almost 10 times. Here follows an actual sample of the output from the test case on my computer (an 2012 iMac): Light load ========== Sequential: 22361 µs Parallel: 2586 µs Ratio: 9 Heavy load ========== Sequential: 254512 µs Parallel: 5246 µs Ratio: 49