Back in 2016, I was working for a small company building digital interactives with web technologies. Most of the time, I worked on projects for museum kiosks and things of that sort, but this particular project had me writing code for a cruise ship. The project consisted of a giant 4k touch screen where up to four guests at a time could scroll through carousels of the various ports they were going to visit on the trip. The user could then click one of these port cards and a large detail view with more info about the port would appear in the UI.
This interaction, selecting the port and displaying the detailed information in a different part of the UI (this was pre-Portals) turned out to be an expensive operation. My test data was only a few dozen items in an array, but the cruise ship was storing hundreds of these ports. Once we got some real test data (which you should try and get as soon as possible in your work), you could see noticeable jank when the user made their selection. The lookup of the info was too slow. What could I do?
Lucky for me, I had started to study some computer science fundamentals and had learned a bit about big O notation and tradeoffs in performance we make with arrays and objects. I won’t go into the details as I have already talked about this in a blog post a while back, but knowing that the lookup speed for on an array is an operation, i.e. linear time, and doing so for an object is an operation, i.e. constant time, helped me make the right decision to change my collections from arrays to objects. This solved the performance problem and was a big win for the project.