github/dejavu
1
0
Fork 0
mirror of https://github.com/correl/dejavu.git synced 2024-11-23 11:09:52 +00:00
Code Issues Projects Releases Packages Wiki Activity

Merge pull request #217 from timgates42/bugfix/typo_multithreading

Browse source 
Fix small typo: mutlithreading -> multithreading
This commit is contained in:
Will Drevo 2020-06-02 17:09:18 -07:00 committed by GitHub
commit 16d7f1d5d3
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
README.md
View file

@ -282,7 +282,7 @@ Notice of course since the matching itself is single threaded, the matching time
if we disregard the miniscule constant term. if we disregard the miniscule constant term.
The overhead of peak finding is the bottleneck - I experimented with mutlithreading and realtime matching, and alas, it wasn't meant to be in Python. An equivalent Java or C/C++ implementation would most likely have little trouble keeping up, applying FFT and peakfinding in realtime. The overhead of peak finding is the bottleneck - I experimented with multithreading and realtime matching, and alas, it wasn't meant to be in Python. An equivalent Java or C/C++ implementation would most likely have little trouble keeping up, applying FFT and peakfinding in realtime.
An important caveat is of course, the round trip time (RTT) for making matches. Since my MySQL instance was local, I didn't have to deal with the latency penalty of transfering fingerprint matches over the air. This would add RTT to the constant term in the overall calculation, but would not effect the matching process. An important caveat is of course, the round trip time (RTT) for making matches. Since my MySQL instance was local, I didn't have to deal with the latency penalty of transfering fingerprint matches over the air. This would add RTT to the constant term in the overall calculation, but would not effect the matching process.