5 ms·

In practice you might get through the night with a memory-hogging process but that's not how you get to scale.

capableweb 5y ago
How can people make generalized statements like this without anything about the use case or problem that would have to be solved? You have exactly 0 information available and yet you make a comment like this? Is this why we have cargo-culting? Not every solution to a problem needs to use as little memory as possible. And also not every solution can ignore memory usage. It depends, of course. Since this thread is about throughoutput and optimizing for that, I could tell you that most times I've been put in charge for optimizing throughoutput, having low memory usage have been pretty far down the list.
- spacemanmatt 5y ago
  > Not every solution to a problem needs to use as little memory as possible Those problems are called "one-offs" relative to things I design for scale.
  - capableweb 5y ago
    ... Yes, "relative to things I design" You think that applies to everyone? You think that comes close to applying to people focusing on improving throughoutput specifically?
  - kaba0 5y ago
    Unless you talk about embedded, I have to disagree. RAM is the cheapest resource to scale and it will likely continue to grow without problems. There are server machines with 1TB of RAM available. And in the domain where Java is used, it uses totally apt amounts of RAM compared to other managed languages.
- papaf 5y ago
  Not every solution to a problem needs to use as little memory as possible. But that's not the point. People aren't suggesting micro managing memory. Java has a well deserved reputation of being a memory hog and its using 20x what is needed in this benchmark.
  - kaba0 5y ago
    In optimizations, you focus on a few metrics, like throughput, latency, resource usage, but deciding to improve one can (and usually does) impact the others. Java (that is, OpenJDK) usually trades of RAM for throughput. And compared to high-level languages doing comparable work, it doesn't use much memory. Of course a low-level language like Rust can be more lean, but that's beside the point. And in this case presumably, Rust could be made to have a better throughput by using more memory.

How can people make generalized statements like this without anything about the use case or problem that would have to be solved? You have exactly 0 information available and yet you make a comment like this? Is this why we have cargo-culting? Not every solution to a problem needs to use as little memory as possible. And also not every solution can ignore memory usage. It depends, of course. Since this thread is about throughoutput and optimizing for that, I could tell you that most times I've been put in charge for optimizing throughoutput, having low memory usage have been pretty far down the list.

spacemanmatt 5y ago
> Not every solution to a problem needs to use as little memory as possible Those problems are called "one-offs" relative to things I design for scale.
- capableweb 5y ago
  ... Yes, "relative to things I design" You think that applies to everyone? You think that comes close to applying to people focusing on improving throughoutput specifically?
- kaba0 5y ago
  Unless you talk about embedded, I have to disagree. RAM is the cheapest resource to scale and it will likely continue to grow without problems. There are server machines with 1TB of RAM available. And in the domain where Java is used, it uses totally apt amounts of RAM compared to other managed languages.
papaf 5y ago
Not every solution to a problem needs to use as little memory as possible. But that's not the point. People aren't suggesting micro managing memory. Java has a well deserved reputation of being a memory hog and its using 20x what is needed in this benchmark.
- kaba0 5y ago
  In optimizations, you focus on a few metrics, like throughput, latency, resource usage, but deciding to improve one can (and usually does) impact the others. Java (that is, OpenJDK) usually trades of RAM for throughput. And compared to high-level languages doing comparable work, it doesn't use much memory. Of course a low-level language like Rust can be more lean, but that's beside the point. And in this case presumably, Rust could be made to have a better throughput by using more memory.