# So, We Are Writing Efficient Software Again > **Source:** [https://lorbic.com/so-we-are-writing-efficient-software-again/](https://lorbic.com/so-we-are-writing-efficient-software-again/) > **Author:** [Vikash Patel](https://vikashpatel.net) > **Published:** June 17, 2026 > **Reading Time:** 6 min > > *This is the raw Markdown source of the article from the [Lorbic Technical Journal](https://lorbic.com/).* --- I wanted to upgrade the RAM in my PC. Nothing fancy. I bought 32GB in 2024 and I wanted to double it. I opened a tab, checked the price, and closed the tab. Then I sat quietly for a moment. The same 32GB kit I bought in 2024 now costs more than double. DDR5 prices have gone up roughly 400% since mid-2025 [1]. DDR4 is not much better. A kit that cost $60–$90 in late 2025 now sells for $150–$180 [2]. I did not upgrade my RAM. I opened my code editor instead. --- ## What happened Two things happened at the same time. **AI ate the memory market.** You know the old meme: "why is my PC slow?" "the cat ate my RAM." Funny because cats do not eat RAM. Except now the cat is a data center, and the RAM is real, and it is not funny anymore. Data centers need enormous amounts of memory to run inference workloads. Manufacturers are happy to sell high-margin server chips to hyperscalers. The consumer market gets whatever is left. Memory shortages are expected to last until at least Q4 2027 [3]. **Tariffs made everything worse.** On top of that, there are now 25% tariffs on many semiconductor imports [4]. At some point ASUS warned that laptops could cost 30% more [5]. I read that headline, closed it, and stared at my ceiling for a while. The best joke in this whole situation is that the people responsible for the price increase are the same companies whose tools we use to write more code, faster, with less thought. We used AI to produce bloated software at scale, and now AI is pricing us out of the hardware to run it. --- ## The villains Let us talk about what we built during the cheap hardware era. Electron. The framework that takes a web app and wraps it in its own copy of Chrome. Discord, Slack, VS Code: all Electron apps. Each one ships with a browser runtime that uses hundreds of megabytes before you open a single document. Slack on startup can use 400MB or more. You are running a browser to run a chat app inside a browser. `node_modules`. The folder that contains the internet. A fresh React project can have 300MB of dependencies before you write one line of application code. The `is-odd` package has 70 million weekly downloads. It is 6 lines long. It checks if a number is odd. Spring Boot. A Java framework where the "Hello World" service takes 45 seconds to start and uses 512MB of heap. There are enterprise teams who have been waiting for their local dev server to start since 2019. Nobody blamed the developers, because there was not much to blame them for. Hardware was cheap, abstraction genuinely helps, and shipping faster is a real goal. The incentives just did not reward caring about memory. --- ## Back to the future Here is the funny part. We are now back to thinking like programmers from the 1980s. In 1984, you had 64KB of RAM. You counted every byte. You decided which data to keep in memory and which to load from disk because you had no real choice. Carmack's DOOM ran on a 386 with 4MB of RAM. The Apollo Guidance Computer had 4KB of RAM and landed humans on the moon. The demoscene still fits entire animated 3D worlds into 4KB executables, just because they enjoy the constraint. Then RAM got cheap, CPUs got fast, and cloud servers became easy to rent by the hour. Writing inefficient software stopped having real consequences, so people mostly stopped thinking about it. --- ## A memo from 1984 **FROM:** A programmer who wrote a ray caster in 640KB **TO:** Modern software engineers **RE:** Your allocator We have reviewed your code. A few notes. Your struct has 7 bytes of padding between the boolean and the integer. This happens on every element of a slice with ten million entries. You are wasting 70MB of RAM for no reason. We could have fit a spreadsheet application in that space. Your dependency tree has a package that checks if a string is empty. It has its own dependency. That dependency has a dependency. We checked: none of them check if the string is empty correctly. Your Docker image is 2.1GB. Our entire operating system was 160KB. We are not angry. We are just disappointed. Regards, 1984 --- So, we are writing efficient software again. --- ## What this means for code If RAM is expensive, your code's memory usage is a cost. Not a performance metric. An actual money cost. A machine that needs 64GB instead of 16GB costs significantly more to buy or rent. A service that allocates 200MB instead of 2GB runs on a smaller, cheaper instance. When you multiply that across a fleet, the difference is real budget. A few things worth thinking about: **Struct layout.** I wrote about this in [A Love Letter to the L1 Cache](../love-letter-to-the-l1-cache/). Compiler padding from bad field ordering can make your structs 50% larger than they need to be. On a tight memory budget, that inflates your working set directly. Run [`betteralign`](https://github.com/dkorunic/betteralign) on your Go codebase and see what it finds. **Allocations.** Every allocation that is not necessary is now more expensive than it was. In Go, this means thinking about whether you should preallocate a slice, whether that intermediate `[]byte` is avoidable, and whether a sync.Pool makes sense for objects you create at high frequency. **Dependencies.** Every library has a memory footprint. Pulling in a 10,000-line package for one function is harder to justify when RAM costs three times what it did in 2024. --- ## A small confession I am not old enough to have written code under real memory constraints. I did not count bytes in 1984. I did not have to. By the time I started programming, RAM was cheap and getting cheaper, and nobody expected you to care. But I have always liked writing code that does not waste things. Not because I had to, just because it feels better. A [loop that fits in cache](../love-letter-to-the-l1-cache/), a struct that has no padding it does not need, a service that uses 80MB instead of 800MB: these feel like better solutions, the same way a tight paragraph feels better than a loose one. After I decided not to upgrade my RAM, I ran `betteralign` on my current project. It found 14 structs with suboptimal field ordering. I felt a little embarrassed, fixed them, and watched the working set of the main loop drop by about 18%. I did not buy any new hardware. I just stopped wasting the hardware I already have. The programmer in the memo above would say "took you long enough". They would be right. But at least I got there. --- ## References [1] [G.SKILL Addresses Sharp DDR5 RAM Price Increases](https://www.neowin.net/news/gskill-addresses-sharp-ddr5-ram-price-increases-for-2025-2026/) — Neowin [2] [RAM Price Index 2026](https://www.tomshardware.com/pc-components/ram/ram-price-index-2026-lowest-price-on-ddr5-and-ddr4-memory-of-all-capacities) — Tom's Hardware [3] [Memory Shortages To Last Till Q4 2027](https://wccftech.com/memory-ddr5-ddr4-shortages-last-till-q4-2027-higher-prices-throughout-2026/) — WCCFtech [4] [Trump Tariffs to Hike PC Costs at Least 20%](https://www.techpowerup.com/335054/trump-tariffs-to-hike-pc-costs-at-least-20-system-integrators-take-the-biggest-blow) — TechPowerUp [5] [Server CPU Prices Up as Much as 20% Since March](https://www.trendforce.com/news/2026/04/22/news-server-cpu-prices-up-as-much-as-20-since-march-intel-may-raise-prices-another-8-10-in-2h26/) — TrendForce