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

0 files changed, 0 insertions, 0 deletions