3 ms·

It is more true in good code than it is in bad code. If you use atomic reference counting everywhere or you're constantly allocating memory and freeing it all

It is more true in good code than it is in bad code. If you use atomic reference counting everywhere or you're constantly allocating memory and freeing it all over the place, like a lot of "modern" code, you do tend to get quite flat profiles. But in good code, which allocates very infrequently, and is designed around flat arrays of data being processed in loops, you naturally do sit in tight loops a lot.

kllrnohj 3y ago
No, it still isn't true. Consider things like a web browser. Huge codebases where damn near the entire thing is "hot." Or OS's like iOS and Android - again, huge codebases where everything is "hot" (everything is either impacting responsiveness or battery life, after all), and vanishingly few if any "super hot tight loops." Same again with game engines like Unreal. It does have data processing hot loops like physics simulations, but it also has audio paths, rendering, AI, etc... that are also all still very much hot. Even the code that does loading, a "rare" event, is still hot because the user is blocked on it. The "hot data processing loop" definitely exists in some systems, notably those that really just do one single thing, but those are also far from even the majority case. At least not on anything where the end user is directly paying the computational bill (aka, very few client apps fit the "single hot loop" profile) But if you go pitch Apple with a "hey, we want iOS to be 20-30% slower because some people are uncomfortable with narrow contracts" they would rightly laugh you right out of the room.
- memefrog 3y ago
  Web browsers are the worst offenders for what I described: highly dynamic retained-mode GUIs with huge amounts of memory allocation all over the place. They are bloated and very much badly designed, so even simple websites slow any 5+-year-old computer to a crawl. If people cared about performance (including latency and power usage) on mobile they wouldnt write such heavy apps. Reality is, people plug their phones in every day and so power usage isnt actually that important. Kept in mind, but clearly not optimised for.

kllrnohj 3y ago

No, it still isn't true. Consider things like a web browser. Huge codebases where damn near the entire thing is "hot." Or OS's like iOS and Android - again, huge codebases where everything is "hot" (everything is either impacting responsiveness or battery life, after all), and vanishingly few if any "super hot tight loops." Same again with game engines like Unreal. It does have data processing hot loops like physics simulations, but it also has audio paths, rendering, AI, etc... that are also all still very much hot. Even the code that does loading, a "rare" event, is still hot because the user is blocked on it. The "hot data processing loop" definitely exists in some systems, notably those that really just do one single thing, but those are also far from even the majority case. At least not on anything where the end user is directly paying the computational bill (aka, very few client apps fit the "single hot loop" profile) But if you go pitch Apple with a "hey, we want iOS to be 20-30% slower because some people are uncomfortable with narrow contracts" they would rightly laugh you right out of the room.

memefrog 3y ago
Web browsers are the worst offenders for what I described: highly dynamic retained-mode GUIs with huge amounts of memory allocation all over the place. They are bloated and very much badly designed, so even simple websites slow any 5+-year-old computer to a crawl. If people cared about performance (including latency and power usage) on mobile they wouldnt write such heavy apps. Reality is, people plug their phones in every day and so power usage isnt actually that important. Kept in mind, but clearly not optimised for.