Your JSGF looks good, but the decrease in speed is part and parcel of JSGF/FSG on the device. I also think grammars are a good idea for many projects so in order to help with that, I’ve added a couple of major features and a plugin in recent versions, which might get you to the performance you’d like to see.
To start out, I developed a new standard grammar language for stock OpenEars that allows you to create dynamically generated grammars at runtime. You can read about it here:
And here is more about it from CMU speech:
Using this format instead of a single pre-written JSGF file can help you get that speed back by letting you work with multiple smaller grammars that are situationally appropriate depending on the UI branch the user is in. The grammars can be quickly switched between while the recognition loop is running, and generated very quickly from arbitrary input, so you can be very efficient creating the smallest possible grammars (and this will also help recognition). It will also, naturally, make it much faster and simpler to create and edit grammars.
If that approach doesn’t help, the next option is to check out RuleORama:
RuleORama is a paid plugin that uses the same grammar language as stock OpenEars described above, but it creates a sort of pseudogrammar which is much faster to return results, as fast as just using a language model. Even with RuleORama you would probably want to reduce your one large grammar into a few smaller ones that are separated by the phase of the decision tree that the user is in, just because RuleORama currently has some hard limits on complexity.