From cc9faec76ecef4c0e99ce94b053f4b14ea49fd54 Mon Sep 17 00:00:00 2001 From: Tim Gates Date: Mon, 11 Nov 2019 07:47:40 +1100 Subject: [PATCH] Fix small typo: mutlithreading -> mutlithreading --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 7ec3ccd..4ad5ac2 100755 --- a/README.md +++ b/README.md @@ -280,7 +280,7 @@ Notice of course since the matching itself is single threaded, the matching time 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.