I put together this tool to estimate runtime complexity given the input size and max time the algorithm has available.
I was motivated by competitive programming.
Sometimes the problem size is sufficiently small and your algorithm has enough time to be naive.
I lacked an intuition for how input size and complexity translates into time.
My intuition was limited to: O(N^2) is bad unless the input size was ~10,000.
Putting this tool together, I feel like I have a better intuition now.
Hopefully exploring the tool will improve your intuition.
If you didn't enable javascript, take a look at the table at the bottom of the page to see how input size and complexity translate to time.
I was hoping for a resource similar to "Latency Numbers Every Programmer Should Know"[1] to help me ballpark how long my algorithm would take before implementing it. I put together a table at the bottom of the page to explore the powers of 2, time, and the runtime complexity. Eventually I realized I could take a step further and ask for a deadline and input size and I could estimate the required runtime complexity.
1 comment
[ 3.3 ms ] story [ 17.4 ms ] threadI was hoping for a resource similar to "Latency Numbers Every Programmer Should Know"[1] to help me ballpark how long my algorithm would take before implementing it. I put together a table at the bottom of the page to explore the powers of 2, time, and the runtime complexity. Eventually I realized I could take a step further and ask for a deadline and input size and I could estimate the required runtime complexity.
[1] https://colin-scott.github.io/personal_website/research/inte...