4 ms·

> The cost of each new field is rarely considered Most developers, in Java and in most other languages, do not consider the cost of every field, but I can tell

by pron 5mo ago

> The cost of each new field is rarely considered Most developers, in Java and in most other languages, do not consider the cost of every field, but I can tell you that people who need micro-optimisations certainly do care, and in Java's standard library, a layout is very much a concern (except, as always, you want to optimise what really matters; there's no point in optimising something that is unlikely to be a hot spot in a real program). Sometimes, though, you want to intentionally spread out the layout to avoid cache line sharing when concurrency is involved. You will find such examples in the standard library, too.

re-thc 5mo 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 5mo ago
  If the previous commenter won't say that, I will
- Retr0id 5mo 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 5mo 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 5mo 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 5mo 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 5mo 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.
- LoganDark 5mo ago
  It doesn't take a "bad developer" to not consider the cost of every field...
- perching_aix 5mo ago
  No, it means the opposite.
petra 5mo ago
And probably, those optimization could be automated by LLM's.

by pron 5mo ago

re-thc 5mo 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 5mo ago
If the previous commenter won't say that, I will
Retr0id 5mo 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 5mo 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 5mo 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 5mo 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 5mo 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.
LoganDark 5mo ago
It doesn't take a "bad developer" to not consider the cost of every field...
perching_aix 5mo ago
No, it means the opposite.

petra 5mo ago

And probably, those optimization could be automated by LLM's.