You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When looking at the code I saw the viterbi state is held inside the context and mutated. This prevents the tagger from running multiple calls to tag concurrently and limits performance for users where they want to do tags concurrently over multiple elements. Instead they'll need to wrap the tagger in a mutex or clone it and all the data (including the mutable state).
An alternative design which would be more multi-threading friendly would be to split the fields that mutate into a new struct something like ViterbiState and change viterbi implementation into fn viterbi(&self, state: &mut ViterbiState) and then make the tag function in the tagger fn tag(&self, xseq: &[T]) where it creates a ViterbiState and passes it into the call to viterbi. This would also remove/simpliy a bunch of the reset code
The text was updated successfully, but these errors were encountered:
When looking at the code I saw the viterbi state is held inside the context and mutated. This prevents the tagger from running multiple calls to tag concurrently and limits performance for users where they want to do tags concurrently over multiple elements. Instead they'll need to wrap the tagger in a mutex or clone it and all the data (including the mutable state).
An alternative design which would be more multi-threading friendly would be to split the fields that mutate into a new struct something like
ViterbiState
and change viterbi implementation intofn viterbi(&self, state: &mut ViterbiState)
and then make the tag function in the taggerfn tag(&self, xseq: &[T])
where it creates aViterbiState
and passes it into the call to viterbi. This would also remove/simpliy a bunch of the reset codeThe text was updated successfully, but these errors were encountered: