‹ BackHN Continuity

Thread

Saving another 100TB of RAM

488 points · 123 comments · f311a

  1. zer0x4d · · focus · HN ↗
    Incredibly happy to see this series of CF articles. I was always so proud of devs back in the days where RAM and processing were scarce and who had to get creative to fit even the most basic stuff in the budget. It seemed to me that after RAM and processing became abundant, most gave up on optimization and focused on shipping instead which meant now that even with several cores, a basic notepad or music player failed to work. In a way, RAM becoming more expensive has ushered in a new era of forced optimizations, which I'm really happy for
    1. jfengel · · focus · HN ↗
      I don't remember those days with a ton of fondness. Yes, the challenge was fun, but I really wanted to ship it and get my product in the hands of customers. Now I can spend more time thinking about what they want and less time about what the computer wants.
      1. rstat1 · · focus · HN ↗
        And its this obsession with shipping things as fast as possible quality be dammed that got us basic weather apps that eat a gigabyte+ of RAM.
        1. locknitpicker · · focus · HN ↗
          > And its this obsession with shipping things as fast as possible quality be dammed (...)

          You seem confused. Allocating more memory than optimal levels is not a measure of quality. Similarly, a web page is not suddenly lower quality if an image asset is 50kb instead of 25kb. And how much complexity and engineering effort and bugs are you willing to tolerate to halve your memory allocations?

          You are conflating quality with mindless minimization, not even knowing or caring that are the tradeoffs. The blog post you're commenting on starts by presenting the case for celebrating small improvements, even 1% improvements at a time. A similar 1% improvement in a mobile app is at like 1MB. Do you ever notice it? How many hours of engineering effort are you hoping to spend on this nonsense? And you prefer to spend it on this or in actually fixing a bug or implementing a feature?

          This puerile conflation of minimization with quality suggests your personal notion of quality has no bearing on what quality actually is.

          1. ffsm8 · · focus · HN ↗
            > And how much complexity and engineering effort and bugs are you willing to tolerate to halve your memory allocations?

            You seem to be confused about this relationship. It's usually exactly the opposite.

            The wasteful applications are generally not well reasoned about and half assed implementations. That's why they're guzzling resources

            There is ofc a middle ground, because targeting eg incredibly resource constrained embedded systems will naturally increase complexity, but that's something entirely different to the scenario this discussion was about up to this point.

            1. BSDobelix · · focus · HN ↗
              Exactly, that`s why i refuse to call 99.9% of "software engineers" engineers. Imagine you optimize a aircraft turbine 1%....man you get to drink a pool of champagne with the highest ceo's and aircraft carriers try to buy that turbine as fast as possible.

              But with software and a install base of some millions 1% optimization is seen as wasteful, its like software slop is acceptable since forever because hardware gets faster, and electricity is "green" anyway.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.