London | 25-SDC-NOV | Jesus del Moral | Sprint 2 | Improve with Precomputing

[delmorallopez]

Common prefix

Count letters

[cjyuan]

Can you use complexity to explain how the new implementation is better than the original implementation?

[cjyuan]

Can you justify the use of @lru_cache? Do you expect it to always improve the performance?

[delmorallopez]

In the original version, we compare every string with every other string. If there are a lot of strings, the number of comparisons grows very quickly because it’s roughly proportional to the square of the number of strings. So doubling the number of strings makes the work grow by about four times.

In the new version, we first sort the strings. Sorting does add some work, but after sorting we only compare neighbouring strings instead of every possible pair. That reduces the number of prefix comparisons dramatically, from “compare everything with everything” to just “compare each string with the next one”.

As a result, the work now grows much more slowly as the number of strings increases. For large inputs, this makes a very noticeable difference in performance compared to the original approach.

So overall, the new implementation scales much better as the list gets bigger.

In this version, @lru_cache stores the result of cached_find_common_prefix(left, right) so that if the same pair of strings is compared again, we can return the result immediately instead of recomputing it.
In this specific implementation, we only compare each adjacent pair once after sorting. That means the same pair of strings is not normally recomputed. So in practice, the cache is unlikely to provide much benefit here.
So I have removed it

[cjyuan]

Whether lru_cache can help or not really depend on the characteristics of the strings we are comparing. Removing it is optional; it's more important to understand its pros and cons, which you did. Good job!

[cjyuan]

Very clever approach.