aboutsummaryrefslogtreecommitdiffstats
path: root/bootstrap/lib/kernel/ebin/file_io_server.beam
diff options
context:
space:
mode:
authorBjörn Gustavsson <[email protected]>2015-02-18 17:43:18 +0100
committerBjörn Gustavsson <[email protected]>2015-02-20 09:56:41 +0100
commitf342b0322f0c594f18e9b5dffd0c5c751804b47f (patch)
tree161d47325490ccc448e9ccbb27fcdd6ae991b01e /bootstrap/lib/kernel/ebin/file_io_server.beam
parent36a515e52d89a6a5f87c271bdea794394ca35d27 (diff)
downloadotp-f342b0322f0c594f18e9b5dffd0c5c751804b47f.tar.gz
otp-f342b0322f0c594f18e9b5dffd0c5c751804b47f.tar.bz2
otp-f342b0322f0c594f18e9b5dffd0c5c751804b47f.zip
beam_jump: Eliminate pathologically slow compilation
José Valim noticed that code such as: match(1) -> 1; match(2) -> 2; match(3) -> 3; ... match(1000) -> 1000. would compile very slowly. The culprit is opt/3 in beam_jump. What happens is that opt/3 will rewrite this code: select_val ... label 1 jump 1000 label 2 jump 1000 ... label 999 jump 1000 label 1000 return very slowly to this code: select_val ... label 1 label 2 ... label 999 label 1000 return The reason for the slowness is that when opt/3 sees this sequence: label 1 jump 1000 ... it will remove the label (storing it in a dictionary), and pick up the previously processed instruction from the accumulator: select_val ... jump 1000 label 2 jump 1000 ... That is done in order to process all labels before the jump and also to get rid of the jump instruction if the previous instruction is an "unreachable after". In this case, re-processing the sequence will remove the now unreachable jump instruction: select_val ... label 2 jump 1000 ... The problem is that re-processing the select_val instruction is expensive. The instruction has a list of 1000 labels, all of which will be added (again) to the set of referenced labels. The select_val instruction will be re-processed again and again until all labels and jumps have been gobbled up. In the original version of beam_jump, opt/3 was not called repeatedly until a fixpoint was found, but was expected to do all its optimizations in one pass. The fixpoint iteration was added later. Since we now have the fixpoint iteration, there is no need to do everything in a single pass. When we encounter a jump, we will collect all previously seen labels and put them into the dictionary, and then we will move on. As a further optimization, we will look for sequences like this: jump X label ... jump X and replace them with: label ... jump X In the example above, that will avoid 1000 updates of the dictionary. After applying this optimization, compilation of the pattern went from roughly 55 s to 0.1 s for the example above but with 10000 clauses. Reported-by: José Valim
Diffstat (limited to 'bootstrap/lib/kernel/ebin/file_io_server.beam')
0 files changed, 0 insertions, 0 deletions