Comment by hintymad

Comment by hintymad 4 days ago

19 replies

> That said there are a ton of cons.

Like the amazing story where a L7 insisted rewriting a python-based CLI tool in Rust, all in the name of performance even though the majority of the time was spent on HTTP calls?

What's more amazing is that the manager of the team thought that was an L7 scope and a great achievement.

ants_everywhere 4 days ago

> even though the majority of the time was spent on HTTP calls?

I'm not sure why this detail is relevant. The CPU it consumes is still CPU. Hypothetically, if a rewrite saves $100 million annually in compute, why does it matter that the majority of its time isn't spent in compute? It's still $100 million.

  • andrewflnr 3 days ago

    I took that to mean the tool was IO-bound, so it wasn't using much CPU to start. So if there was even that tiny sliver of slack CPU (and that's almost definitely the case on a desktop or other dev machine), then saving that tiny bit of CPU actually saved no money, since it was already riding on the spare capacity of other investments. That just leaves the cost in engineer-hours to rewrite the program.

    • ants_everywhere 3 days ago

      IO-bound doesn't mean it doesn't use much CPU. A tool can use a lot of IO and also a lot of CPU.

      > then saving that tiny bit of CPU actually saved no money

      this doesn't follow

      > since it was already riding on the spare capacity of other investments

      nor does this

      Take for example a CLI that downloads and verifies the Bitcoin blockchain. It may spend most of its time downloading blocks, but it spends a ton of time calling SHA256 to verify those blocks. Similarly with a tool that downloads and checksums large files like Docker images.

      If you have a fleet of 650K developer machines all running this util, then at some point it becomes cost effective to optimize the CPU usage.

      Whether that point was reached in this example is not something I know. It seems like the L7 and their manager believed it was. But OP believes it wasn't. Either way, we don't know from OP's description of the situation.

      • andrewflnr 3 days ago

        Sure, something like that is technically consistent with the description, but unlikely to be relevant. If you're thinking of a program that downloads a bunch of data and then does a bunch of cryptographic operations on it, what are the odds that the first description in your mind is "spends most of its time on HTTP requests"? Slim, I'd say, even if it's technically the majority of the time.

  • lokar 4 days ago

    Have you used many cli tools that consume a meaningful amount of cpu (in terms of cost)? They are generally used by a human, so the scale can’t be all that big.

    • ants_everywhere 3 days ago

      Yeah, go to a place with poor bandwidth and run any tool that downloads and hashes large files. It will spend a large time waiting on the download and also a large time hashing the files.

      • [removed] 3 days ago
        [deleted]
  • lazyant 4 days ago

    If the CLI runs on an engineer's laptop (like AWS CLI for ex) then it doesn't matter