3 ms·

> Doing fork/exec for the mkdir tool is still many times slower that calling a good library function. Would it be noticeably slower to the point it's measurabl

• thebackup 5y ago
  Premature optimization is a common disease amongst C and C++ devs. I often come across code that is written in an obscure/complex way just because someone thought execution speed triumphs code readability. In most cases (around 9 times out of 10) it is on a non-time-critical path of the code and the developer who wrote it didn't even bother to run a profiler on it. My work would be significantly easier if we could learn to prioritize code readability.
  • mgaunard 5y ago
    The point of those languages is to make it explicit when you're doing ridiculously costly things so that you're forced to do a reasonable implementation instead.
    • tylerhou 5y ago
      I disagree that C++ makes expensive operations explicit; see the copy constructor and the copy assignment operators. C, maybe.
      • mgaunard 5y ago
        A C++ developer would know what an assignment or copy entails and would spot them on sight.
        • tylerhou 5y ago
          It's impossible to tell whether a specific line of code makes a copy without knowing the types of all values. i.e. std::vector<int> numbers = Func(); may or may not make a copy depending on the signature of Func. So it's not clear at the callsite how expensive that line of code is. This is unlike Go (which has this explicitly as philosophy) where you need to call a copy function/use append to make a copy of a slice.
          • mgaunard 5y ago
            Knowing the declarations of the various names a piece of code uses is of course a requirement in order to understand what it does. In that example, there would always be a move or copy there, though there are scenarios in which it might be elided.
    • klyrs 5y ago
      No, any language that allows operator overloading can hide ridiculously costly operations behind mundane-looking code. C is pretty good about that, but C++ is not: you can even overload the comma operator!
      • mgaunard 5y ago
        Consider a + b + c. When you read the code, you know what the types of a, b and c are. You know whether they're built-in types, and therefore whether those operator expressions are actually function calls. Nothing is hidden, so long as the programmer doesn't make invalid assumptions based on his experience with other, different languages.
        • klyrs 5y ago
          Your point appears to be "if you know the entire codebase, nothing is hidden." This is tautologically true of all languages. If you're accustomed to working on small projects, then that attitude will work out for you. If you work on large codebases, it isn't always so easy, especially if folks use a lot of template magic. In your case, if a, b, and c are all the same type, then b+c can return a completely different type, and you'll need to track that down before you know what type a+(b+c) will have. And in that case, (a+b)+c can have a different type from a+(b+c). If you've memorized the associativity rules for the language, you'll know what to expect -- but it's not at all obvious from the notation. And, sure. If you know absolutely everything about the language and everything about the codebase, you can make accurate predictions about the behavior of any given line. But if you're coming into a new codebase, there's no way to know at a glance what a given line of code is going to cost. That's what folks are calling hidden complexity. Oh -- and thanks to the auto keyword, you don't always know the types of a, b, and c without hunting things down.
          • mgaunard 5y ago
            You don't need to know the whole codebase to understand a piece of code, just what the declarations of the names being referenced in that piece of code are (in C++, a name may be a macro, a type, a template, a variable or a function, and depending on which kind, may have all kinds of other properties attached). Yes, you need to look at the declarations of names to know what the resulting type of expressions involving those names is. I don't see that as being surprising or unusual. The same is also true in C.
• hamburglar 5y ago
  It depends a lot on how often you’re trying to do it and the conditions you’re doing it under. I’ve worked on a couple of projects where I own an agent process that runs on thousands of machines that are not mine (so I have no control of whether they are overloaded or in some pathological state), some of which are bumping up against memory and/or cpu and or IO limits, and a single blocking system call is many orders of magnitude more practical than the overhead of fork/exec and the dozens or hundreds of blocking system calls and memory allocations that entails. This is, of course, an extreme example. But there are definitely cases where it matters a lot.