3 ms·

> I wouldn’t classify it as trivia to know the big-O complexity of an algorithm or to have some idea of the worst-case behaviors you may run into (like insertin

by foofie 3y ago

> I wouldn’t classify it as trivia to know the big-O complexity of an algorithm or to have some idea of the worst-case behaviors you may run into (like inserting already sorted data into a binary tree). It's trivia, and more often than not it's completely useless trivia. Big-O complexity refers to asymptotic complexity which is only theoretically met with very large datasets which are already in the realm of a RDBMS. Until that point, performance is far more sensitive to cache locality and other implementation details. This means that all those trivia numbers don't even match with real world data you get from your own performance tests. So what's the point of wasting time memorizing trivia that doesn't even match real-world observations?

vlovich123 3y ago
Big-o of various data structures is typically trivia not worth remembering but it’s also easy to remember for the most common data structures. For all the other data structure operations it up. But there’s a lot more to data structures than big-O and implementing it yourself is one way to expose yourself to those details (eg cache locality or other things). Crossing abstraction layers requires an understanding of what’s above and below an abstraction. It’s not trivial to have that knowledge and know how to apply it effectively. It also is not relegated to RDBMS. It can come up when dealing with as few as 1M elements. For example, look up the Rockstar long loading time bug that applied an n^2 algorithm accidentally to something like a few thousand or hundred thousand elements. But you seem to be pretty into the ignorance is a virtue mantra so not sure there’s any point in engaging further.
- edgyquant 3y ago
  Big O notation is a description of algorithmic complexity, not “data structures” and it definitely isn’t trivia. One of the two biggest pain points I’ve dealt with with new devs (even experienced ones) is that they ignore time complexity and write god awful slow code. (The other is adding network requests, eg database calls, in loops)
  - randomdata 3y ago
    No, it is definitely trivia. You can just as easily look it up on an as-needed basis. Whether or not developers choose to observe time complexity is orthogonal.
    - edgyquant 3y ago
      Look up what? If I ask a dev the time complexity of a function they’ve just written, what are you expecting them to lookup? They should be able to tell me on the spot and we can discuss if it’s optimal
      - vlovich123 3y ago
        That’s not what this thread chain is about where we’re saying the time complexity for various operations on more obscure but still common data structures (eg btree, trie etc) are trivia that is typically documented by the library providing said data structure. That is distinctly different from being able to perform a big-o analysis on a given piece of code.
      - randomdata 3y ago
        How does that meme go? Oh yeah: Tell us you haven't read the thread without telling you haven't read the thread. But, okay, let's entertain your random tangent. Such a request is emblematic of junior managers/junior manager hopefuls misguidedly trying to wedge their knowledge into the function of the operation. In reality, you don't want to have to build a team that requires discussion about such matters. You need to define clear performance requirements upfront and let the benchmarks speak for themselves. Even if a function is O(N!), but measures successfully within the needs of the application, good enough. It is especially important to encode these requirements in benchmarks as it documents for future developers the same requirements, and ensures they stay within them as code gets modified. The reality is that you won't be around forever. Keeping a team that relies on you to ask such questions is a failing on you. But let's accept, for the sake of discussion, that you have failed your team. One still does not need to remember that kind of information. The function they wrote contains what they need to know, and they can consult the function to ascertain that information as needed – just as you could all by yourself in this scenario. If you like keeping such trivia in active memory, good on ya, but it is never necessary.

by foofie 3y ago

vlovich123 3y ago

Big-o of various data structures is typically trivia not worth remembering but it’s also easy to remember for the most common data structures. For all the other data structure operations it up. But there’s a lot more to data structures than big-O and implementing it yourself is one way to expose yourself to those details (eg cache locality or other things). Crossing abstraction layers requires an understanding of what’s above and below an abstraction. It’s not trivial to have that knowledge and know how to apply it effectively. It also is not relegated to RDBMS. It can come up when dealing with as few as 1M elements. For example, look up the Rockstar long loading time bug that applied an n^2 algorithm accidentally to something like a few thousand or hundred thousand elements. But you seem to be pretty into the ignorance is a virtue mantra so not sure there’s any point in engaging further.

edgyquant 3y ago
Big O notation is a description of algorithmic complexity, not “data structures” and it definitely isn’t trivia. One of the two biggest pain points I’ve dealt with with new devs (even experienced ones) is that they ignore time complexity and write god awful slow code. (The other is adding network requests, eg database calls, in loops)
- randomdata 3y ago
  No, it is definitely trivia. You can just as easily look it up on an as-needed basis. Whether or not developers choose to observe time complexity is orthogonal.
  - edgyquant 3y ago
    Look up what? If I ask a dev the time complexity of a function they’ve just written, what are you expecting them to lookup? They should be able to tell me on the spot and we can discuss if it’s optimal
    - vlovich123 3y ago
      That’s not what this thread chain is about where we’re saying the time complexity for various operations on more obscure but still common data structures (eg btree, trie etc) are trivia that is typically documented by the library providing said data structure. That is distinctly different from being able to perform a big-o analysis on a given piece of code.
    - randomdata 3y ago
      How does that meme go? Oh yeah: Tell us you haven't read the thread without telling you haven't read the thread. But, okay, let's entertain your random tangent. Such a request is emblematic of junior managers/junior manager hopefuls misguidedly trying to wedge their knowledge into the function of the operation. In reality, you don't want to have to build a team that requires discussion about such matters. You need to define clear performance requirements upfront and let the benchmarks speak for themselves. Even if a function is O(N!), but measures successfully within the needs of the application, good enough. It is especially important to encode these requirements in benchmarks as it documents for future developers the same requirements, and ensures they stay within them as code gets modified. The reality is that you won't be around forever. Keeping a team that relies on you to ask such questions is a failing on you. But let's accept, for the sake of discussion, that you have failed your team. One still does not need to remember that kind of information. The function they wrote contains what they need to know, and they can consult the function to ascertain that information as needed – just as you could all by yourself in this scenario. If you like keeping such trivia in active memory, good on ya, but it is never necessary.