3 ms·

> Most developers, in Java and in most other languages, do not consider the cost of every field Are you saying most developers are bad? It’s the equivalent of

by re-thc 4mo ago

> Most developers, in Java and in most other languages, do not consider the cost of every field Are you saying most developers are bad? It’s the equivalent of most employees don’t consider the cost of every action to the employer and is how company spend blows up.

nathanielks 4mo ago
If the previous commenter won't say that, I will
Retr0id 4mo ago
Most likely they just have other priorities. A lot of code is not at all performance-sensitive, or is bottlenecked by some other factor.
pron 4mo ago
I'm saying that most developers aren't writing code where layout is a primary contributor to the program's performance. Even in performance-sensitive applications, only a minority of the team are working on the hot spots. And speaking about costs, knowing what to optimise is the key to software performance. Improving the performance of an operation by 10000x will improve the performance of your program by less than 1% if the operation is only 1% of the profile to begin with. So I'm only saying that most developers don't work on code where the layout is very significant, but some certainly do.
- re-thc 4mo ago
  > I'm saying that most developers aren't writing code where layout is a primary contributor to the program's performance. I've heard this theory before. This isn't just about performance and I don't buy it. I've seen too many examples of this is just a temporary solution so it doesn't matter. >3 years later that "temporary solution" was still there and at the heart of many operations yet it's now to hard and too costly to fix. I've also seen the this is a quick hack. No 1 uses it. It doesn't go through any hot paths. All good. You know what happens? Years later, every service literally goes through it. Again, it's too hard to fix. In the real world these "theories" are really loose. The only fix is every should be aware of what they are doing and do it properly. The it might not happen, etc mindset is dangerous.
  - gf000 4mo ago
    Then what is it that you are saying? That I should use JMH to determine the best layout for my helper class that will be initialized 3 times? Like most of the software (by line of code) is boring plumbing from one service to another with some dumb business logic sprinkled in. Something like a single config option for your database driver matters orderS of magnitude more in many types of applications. It's much more niche to work on stuff where such changes actually matter, like much much more people write boring CRUD backends than those who write physics simulators and audio processing pipelines combined.
    - re-thc 4mo ago
      Consider the cost of every field, of every action. Understand the language, the memory model, etc. Don't do "it works on my machine". Understand the architecture, layout, implications etc. E.g. if you need an int and not a long you should clearly use an int. Wait until you do this every time and things blow up and it's too "hard" to change. It's called be aware of your actions. Take responsibility of what you do. > It's much more niche to work on stuff where such changes actually matter, Not true and that's why there's so much wastage. A lot of things matter. I've seen more times than the other way that simple awareness and changes can pay for my salary, e.g. not updating to newer EC2 instances when they get released in AWS. Even in a mid size company that was hundreds to thousands in savings. I've seen CI/CD pipelines where the developers never considered caching and it takes hours to run. It's not free. When every PR and update (hundreds a day) triggers a run it's a cost and a cost not just on machines but developer time waiting. I can list a lot more examples and everyone in the chain can contribute.
      - pron 4mo ago
        > Consider the cost of every field, of every action. This runs counter to most modern software performance principles. Thanks to modern hardware optimisations (cache hierarchy, ILP, branch prediction), modern compiler optimisations (aggressive inlining that leads to a much wider view), and increased concurrency, the notion of some action having a cost lost most meaning about 20 years ago, and increasingly since. Because how fast some action is now depends on a much broader context of what else is going on in the program (and the machine), action X can be faster than Y in one program and the same or slower than Y in another. Because it's nearly impossible to generalise (and so what was true in your previous program may not be true in your current one unless they're nearly identical), the advice is to first profile your program so that you know how fast or slow different parts are in the context of your particular program and then to focus the optimisation efforts on the hot paths in your program. Otherwise, you may end up spending effort where it makes no difference, and this comes at the cost of optimising what matters, overall harming performance. Taking responsibility means being smart about directing your resources to where they can have the most impact.
LoganDark 4mo ago
It doesn't take a "bad developer" to not consider the cost of every field...
perching_aix 4mo ago
No, it means the opposite.

by re-thc 4mo ago

nathanielks 4mo ago

If the previous commenter won't say that, I will

Retr0id 4mo ago

Most likely they just have other priorities. A lot of code is not at all performance-sensitive, or is bottlenecked by some other factor.

pron 4mo ago

I'm saying that most developers aren't writing code where layout is a primary contributor to the program's performance. Even in performance-sensitive applications, only a minority of the team are working on the hot spots. And speaking about costs, knowing what to optimise is the key to software performance. Improving the performance of an operation by 10000x will improve the performance of your program by less than 1% if the operation is only 1% of the profile to begin with. So I'm only saying that most developers don't work on code where the layout is very significant, but some certainly do.

re-thc 4mo ago
> I'm saying that most developers aren't writing code where layout is a primary contributor to the program's performance. I've heard this theory before. This isn't just about performance and I don't buy it. I've seen too many examples of this is just a temporary solution so it doesn't matter. >3 years later that "temporary solution" was still there and at the heart of many operations yet it's now to hard and too costly to fix. I've also seen the this is a quick hack. No 1 uses it. It doesn't go through any hot paths. All good. You know what happens? Years later, every service literally goes through it. Again, it's too hard to fix. In the real world these "theories" are really loose. The only fix is every should be aware of what they are doing and do it properly. The it might not happen, etc mindset is dangerous.
- gf000 4mo ago
  Then what is it that you are saying? That I should use JMH to determine the best layout for my helper class that will be initialized 3 times? Like most of the software (by line of code) is boring plumbing from one service to another with some dumb business logic sprinkled in. Something like a single config option for your database driver matters orderS of magnitude more in many types of applications. It's much more niche to work on stuff where such changes actually matter, like much much more people write boring CRUD backends than those who write physics simulators and audio processing pipelines combined.
  - re-thc 4mo ago
    Consider the cost of every field, of every action. Understand the language, the memory model, etc. Don't do "it works on my machine". Understand the architecture, layout, implications etc. E.g. if you need an int and not a long you should clearly use an int. Wait until you do this every time and things blow up and it's too "hard" to change. It's called be aware of your actions. Take responsibility of what you do. > It's much more niche to work on stuff where such changes actually matter, Not true and that's why there's so much wastage. A lot of things matter. I've seen more times than the other way that simple awareness and changes can pay for my salary, e.g. not updating to newer EC2 instances when they get released in AWS. Even in a mid size company that was hundreds to thousands in savings. I've seen CI/CD pipelines where the developers never considered caching and it takes hours to run. It's not free. When every PR and update (hundreds a day) triggers a run it's a cost and a cost not just on machines but developer time waiting. I can list a lot more examples and everyone in the chain can contribute.
    - pron 4mo ago
      > Consider the cost of every field, of every action. This runs counter to most modern software performance principles. Thanks to modern hardware optimisations (cache hierarchy, ILP, branch prediction), modern compiler optimisations (aggressive inlining that leads to a much wider view), and increased concurrency, the notion of some action having a cost lost most meaning about 20 years ago, and increasingly since. Because how fast some action is now depends on a much broader context of what else is going on in the program (and the machine), action X can be faster than Y in one program and the same or slower than Y in another. Because it's nearly impossible to generalise (and so what was true in your previous program may not be true in your current one unless they're nearly identical), the advice is to first profile your program so that you know how fast or slow different parts are in the context of your particular program and then to focus the optimisation efforts on the hot paths in your program. Otherwise, you may end up spending effort where it makes no difference, and this comes at the cost of optimising what matters, overall harming performance. Taking responsibility means being smart about directing your resources to where they can have the most impact.

LoganDark 4mo ago

It doesn't take a "bad developer" to not consider the cost of every field...

perching_aix 4mo ago

No, it means the opposite.