3 ms·

Well then further excuses come flying on why he is wrong again, and how performance doesn't matter to them. I have a legacy code base that I until recently work

Well then further excuses come flying on why he is wrong again, and how performance doesn't matter to them. I have a legacy code base that I until recently worked with that domain specific Business Intelligence product built with SOLID principles. 20% of the processes CPU usage was for the GC, whenever you made a dump of the process it was 99% fragmentation of memory and pointer chasing through object trees every time. The customers complain about performance because they aren't getting their data in a timely manner and not getting the savings they were promised with the product. It is not a game but it does math on a bunch of data and there is a requirement to do it in a timely manner, which it is failing. Stop coming with excuses that it is niche, if you are doing anything useful to the data then you might want to pick up on Caseys advice.

kaba0 3y ago
And what exactly is that advice? Most programs are not game engines operating upon millions of entities with the same basic logic. The usual application where GC is most relevant is connected to 10s of services over some network protocol, and often has to load each business object/entity it operates on into memory to check permissions, sometimes even issue another network call, etc. Loading that entity from a list of pointers is absolutely no bottleneck in such a setting, at all - the way you might speed up the app is doing the work on the database itself, which is already written in some low-level language, efficiently. Your anecdote is just a badly written application, I have plenty examples of very performant ones written in managed languages.
- JanneVee 3y ago
  The advice is that consider memory layout when doing repetitive operations on your data. > The usual application where GC is most relevant is connected to 10s of services over some network protocol, and often has to load each business object/entity it operates on into memory to check permissions, sometimes even issue another network call, etc. Loading that entity from a list of pointers is absolutely no bottleneck in such a setting, at all - the way you might speed up the app is doing the work on the database itself, which is already written in some low-level language, efficiently. No my example isn't a complaint on it using GC language. It is that it is loading and unloading business entities multiple times and doesn't take into account that operations could be done linearly much faster instead of hunting a field in object graph to accumulate in various ways. That is how e.g. numpy works if you make sure that the array you do your operation on is of the same type. > Your anecdote is just a badly written application, I have plenty examples of very performant ones written in managed languages. Yes following the ideas of what is considered SOLID principals. The objections isn't managed vs. unmanaged it is going full OO and not giving a shit about how computers work.
  - kaba0 3y ago
    I don’t see how OO is at fault here, though.
    - JanneVee 3y ago
      OO encourages objects graphs scattering your data unpredictably in memory and modern CPU:s likes to have it's data in continuous memory area where it can do prefetching and prediction on where your data resides.
      - gonzo41 3y ago
        That's not really true anymore. RAM is so big these days that most databases can fit into it and be blazingly fast. It's all the classic shit that slows people down. Loops in loops in loops in loop with nested if's. Not understanding the correct way to structure IF statements (Common case first etc).
        shrimp_emoji 3y ago
        > RAM is so big these days that most databases can fit into it and be blazingly fast. ... Compared to L3 cache? Isn't that still at least 10 times faster? That probably only matters in high performance projects though. > the correct way to structure IF statements (Common case first etc) But muh early returns on error D:
        tmtvl 3y ago
        According to Intel* RAM is about 2x L3 cache. Which is about 10x L2, which is about 4x L1. So: RAM := 1 L3 := 2 L2 := 20 L1 := 80 * https://www.intel.com/content/www/us/en/developer/articles/technical/memory-performance-in-a-nutshell.html https://www.intel.com/content/www/us/en/developer/articles/t...
        _aavaa_ 3y ago
        That's latency, and it's for a 16 core. The bandwith is shown there to be at least 1/4.

kaba0 3y ago

And what exactly is that advice? Most programs are not game engines operating upon millions of entities with the same basic logic. The usual application where GC is most relevant is connected to 10s of services over some network protocol, and often has to load each business object/entity it operates on into memory to check permissions, sometimes even issue another network call, etc. Loading that entity from a list of pointers is absolutely no bottleneck in such a setting, at all - the way you might speed up the app is doing the work on the database itself, which is already written in some low-level language, efficiently. Your anecdote is just a badly written application, I have plenty examples of very performant ones written in managed languages.

JanneVee 3y ago
The advice is that consider memory layout when doing repetitive operations on your data. > The usual application where GC is most relevant is connected to 10s of services over some network protocol, and often has to load each business object/entity it operates on into memory to check permissions, sometimes even issue another network call, etc. Loading that entity from a list of pointers is absolutely no bottleneck in such a setting, at all - the way you might speed up the app is doing the work on the database itself, which is already written in some low-level language, efficiently. No my example isn't a complaint on it using GC language. It is that it is loading and unloading business entities multiple times and doesn't take into account that operations could be done linearly much faster instead of hunting a field in object graph to accumulate in various ways. That is how e.g. numpy works if you make sure that the array you do your operation on is of the same type. > Your anecdote is just a badly written application, I have plenty examples of very performant ones written in managed languages. Yes following the ideas of what is considered SOLID principals. The objections isn't managed vs. unmanaged it is going full OO and not giving a shit about how computers work.
- kaba0 3y ago
  I don’t see how OO is at fault here, though.
  - JanneVee 3y ago
    OO encourages objects graphs scattering your data unpredictably in memory and modern CPU:s likes to have it's data in continuous memory area where it can do prefetching and prediction on where your data resides.
    - gonzo41 3y ago
      That's not really true anymore. RAM is so big these days that most databases can fit into it and be blazingly fast. It's all the classic shit that slows people down. Loops in loops in loops in loop with nested if's. Not understanding the correct way to structure IF statements (Common case first etc).
      - shrimp_emoji 3y ago
        > RAM is so big these days that most databases can fit into it and be blazingly fast. ... Compared to L3 cache? Isn't that still at least 10 times faster? That probably only matters in high performance projects though. > the correct way to structure IF statements (Common case first etc) But muh early returns on error D:
        tmtvl 3y ago
        According to Intel* RAM is about 2x L3 cache. Which is about 10x L2, which is about 4x L1. So: RAM := 1 L3 := 2 L2 := 20 L1 := 80 * https://www.intel.com/content/www/us/en/developer/articles/technical/memory-performance-in-a-nutshell.html https://www.intel.com/content/www/us/en/developer/articles/t...
        _aavaa_ 3y ago
        That's latency, and it's for a 16 core. The bandwith is shown there to be at least 1/4.