Constraint Grammar/Speed

From Apertium
< Constraint Grammar
Revision as of 18:09, 15 September 2014 by Unhammer (talk | contribs) (Created page with "Tips on how to speed up your Constraint Grammar. ==Put popular rules first== If a cohort can be fully disambiguated early on, CG won't have to bother with that cohort later a...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Tips on how to speed up your Constraint Grammar.

Put popular rules first

If a cohort can be fully disambiguated early on, CG won't have to bother with that cohort later at all.

E.g. if you two rules that work on nouns, but one of them only matches if there's some rare verb in the context, try to put that rule after the first rule (as long as you still get the correct disambiguation!).

Avoid slow rule types

Regexes

Lots of regex matching ("foo.*bar"r) is typically slow.

(*)

A rule like

"<foo>" ADD (bar) (*) IF …

is much slower than

"<foo>" ADD (bar) ("<foo>") IF …

(vislcg3 might optimise that away in the future?)


Speedy alternatives to CG

  • apertium-tagger is a lot faster than CG, but only supports the same types of rules that the tagger can learn (e.g. select or remove this bigram). (However, if you run apertium-tagger before the CG, your CG has less work to do.)