v1.2.2 Confirm searchTerm
The obvious problem with the previous performance profile is that the expensive search algorithm is run even when the searchTerm is stale. So a potential solution would be to confirm that the searchTerm is the latest one before initiating the expensive search. This can be done pretty easily by adding a confirmSearchTerm function to the webWorker script:
And an extra conditional to the SearchResults handleResults method that listens for confirmSearchTerm requests:
Lets see the performance profile to check whether this has made an improvement:
Its hard to see because they are so quick, but the confirmSearchTerm function is run between each Worker execution stack (see the blue line).
So it is doing its job: before running the expensive search method, our Worker confirms it needs to. And notice that we see 4 Key Character inputs in orange at the top, yet only 3 searches are run. In this case we’ve eliminated one unnecessary search, which is up to a 330ms savings. But previously we’ve seen that several extra searches can queue up and be run unnecessarily, and this will prevent all of them. So our savings can be significant, especially on mobile.
But a keen observer will see we are still wasting time:
The latest search with the up-to-date searchTerm still has to at least wait for any currently running searches in the worker thread to finish. That’s a whopping 84ms (highlighted in blue)! As far as I know, we can’t cancel a stack mid-execution. So surely there’s nothing we can do about that right?
