Improving Context to follow FastContext about medspacy HOT 1 CLOSED

I think this is an interesting idea. Performance of medspacy has been a concern for us but I don't think any of our processes have been able to really stress test the performance. The "extreme example" in the intro is the team I work on and we expect our completed systems to be able to process millions of records per day.

We also work closely with the authors of this paper and they have contributed to other components of medspacy. We can easily ask them if they have any thoughts for speeding up the code inside each component.

I do have a few initial thoughts on it, though:

1. One of our goals with medspacy was to be able to leverage the optimizations and work that others were doing (which was largely done in python for the broader NLP/ML community). Implementing the specialized trie for FastContext would require fully abandoning the spacy matchers and may need to be entirely custom.
2. Medspacy components are not currently compatible with spacy's built-in multiprocessing due to (we believe) some missing or incorrect serialization methods, which is most likely a much quicker path to significant performance increases than implementing the current context algorithm. Parallelization is not a substitute for fastcontext, as mentioned in the paper, but may be a quicker fix for performance than changing the component significantly.
3. We created common internal structures for medspacy's context, sectionizer and target matcher in the last major release. If this change was made, it could possibly be done inside this framework and benefit all three components. This would be more involved that simply implementing fastcontext, but is still a possibility in favor of eventually making the change.

from medspacy.