Every Byte Matters

https://fzakaria.com/2026/06/01/every-byte-matters

by ingve • 2 months ago

281 152 2 months ago

I love to see stuff like this. And an active Vectrex gamedev and PC/Amiga sizecoder I strongly agree with the sentiment!

forinti• 2 months ago

So if you need speed, you just have to swallow your OO programmer's pride and put your data in arrays.

theandrewbailey2• 2 months ago

Maybe someone can write an OO language where arrays of structs are automatically stored as structs of arrays.

mild /s

Mizza• 2 months ago

Are you talking about Zig's MultiArrayList?

fp642• 2 months ago

Odin has some helpers, was one of the more interesting features I found, but never tried. Not sure if you want to consider Odin OO, but well https://odin-lang.org/docs/overview/#soa-struct-arrays

tlb• 2 months ago

There's a package to do this in Julia: https://juliaarrays.github.io/StructArrays.jl/stable/

gryn• 2 months ago

something like this https://crates.io/crates/columnar ?

bob1029• 2 months ago

And avoid moving said data between physical threads as much as possible.

Most of the bottlenecks I see are not due to the organization of data. Unnecessary communication of data is the #1 offender.

burnt-resistor3• 2 months ago

Working set and algorithm diagonalization (work independence) FTW. Immutable data structures and copying often helps to avoid cache invalidation penalties.

jayd166• 2 months ago

If you have hot loops with millions of iterations at a time, structure your code accordingly. Its not anti-OO to choose the right data structure for the job.

kerblang• 2 months ago

... IF that's your main performance problem.

I already know I'm dealing with huge perf issues caused by ORM & lazy-load semantics. I/O abuse is usually going to be so, so much worse than memory/cache issues. Java is mainly used for business information systems, where I/O is king. Plain vanilla memory abuse is also a big one.

But my main problem is a mgmt convinced the magic wand of AI will make all sorts of problems dissapear, and it's going to take 5 years for them to realize nope.

It's still fun to learn about cache optimization though, esp. when someone makes it reasonably digestible like this. And maybe it also helps people to recognize that OOP is not some great over-arching zen truth of truths.

chadgpt34• 2 months ago

If you had the right language you could use AoS syntax with SoA implementation. I heard Jai was going to have this feature?

noelwelsh• 2 months ago

The JVM is currently pretty bad for memory allocation. Every object (i.e. not a primitive) has a header that IIRC is 12 bytes. But there is good news in JVM land: this will be reduced to 8 bytes in the next JVM release, and Project Valhalla will give the tools to do away with headers entirely in some cases. Project Valhalla also has tools to manage off-heap memory, which is important in many cases.

The JVM is an odd place where it requires too much heap to compete with the AOT compiled languages, but its startup time is too slow compared to interpreted languages. I think these enhancements are essential to keep the platform relevant.

kakacik• 2 months ago

Most of real world use of Java platform has next to 0 concerns like those. Some more niche use case may benefit, good, but overall success map isn't changing anytime soon. Reasons for its long term success lie elsewhere.

FartyMcFarter• 2 months ago

Android Java apps' memory consumption is definitely a relevant concern.

re-thc5• 2 months ago

Not true. Lots of large Java deployments with millions to billions in cloud spend. The Java part of it isn’t 0.

Memory isn’t free. CPU isn’t free.

nitwit005• 2 months ago

While this is true, it is true because the applications where it might be a concern avoid using Java.

pron24• 2 months ago

Every object (i.e. not a primitive) has a header that IIRC is 12 bytes. But there is good news in JVM land: this will be reduced to 8 bytes in the next JVM release

Since JDK 25 it's already 64 bits with the `-XX:+UseCompactObjectHeaders` flag [1], but in JDK 27 it will be the default [2].

where it requires too much heap to compete with the AOT compiled languages

Not to compete but to beat, and not too much, but the right amount. Low level languages are optimised for control, not performance (that control translates to better performance in smaller programs, and to worse performance in larger programs), and their particular constraints prevent them from enjoying certain important optimisations, especially those offered by JIT compilation and moving collectors, which remove some overheads that AOT compilers and free-list allocators incur. Their memory management is forced (by their constraints) to optimise for footprint rather than speed.

There are common misunderstandings about memory management and why moving collectors were created to reduce the CPU overheads of malloc/free, especially in large programs, in exchange for what is effectively free RAM. This is why moving collectors are chosen by the languages that are unconstrained enough to use them and have the resources to implement them (Java, .NET, V8). With the exception of Zig (and even there it requires some effort), it's hard for low level languages to use the basic optimisation that's behind moving collectors. I gave a talk about how moving collectors optimise memory management at the last Java One, and it should be available on YouTube soonish [3].

but its startup time is too slow compared to interpreted languages

That hasn't been the case for some time. You are right, though, that startup/warmup time is worse than in AOT compiled languages, and that is the tradeoff of optimising JITs: reduce the overheads associated with AOT compilation in large program in exchange for warmup.

Both startup and warmup have already been improved thanks to Project Leyden's "AOT cache" [4], but it will never be as low as C.

In general, the tradeoff is between optimisations that help large programs vs optimisations that help small programs.

[1] https://openjdk.org/jeps/519

[2] https://openjdk.org/jeps/534

[3]: I can't reproduce the full talk (which goes into the maths of memory management) here but what happened with moving collectors was that until very recently (open source low-latency moving collectors are newer than ChatGPT), they required pauses and so weren't suitable for programs requiring low latencies. As a result, many developers either forgot or never learnt just how incredibly efficient moving collectors are. But the key is that because accessing RAM by necessity requires CPU, using CPU effectively captures RAM even it's not used by the program. Bringing the CPU and RAM usage into a good balance is more efficient than trying to minimise one or the other. This is also the reason why hardware (physical or virtual) is packaged within a very narrow band of RAM/core ratio.

[4] https://www.youtube.com/watch

AlotOfReading3• 2 months ago

    In general, the tradeoff is between optimisations that help large programs vs optimisations that help small programs.

Do you have concrete examples of large scale Java programs that are significantly more performant than comparable programs in native languages like C++? My understanding was that this dynamic hadn't fundamentally changed much since the 2010s, when Java was able to occasionally edge out a win in 1-2 benchmarks and would lose handily in others. My experience is that large scale Java programs remain a bit of a bear even after significant optimization effort (e.g. Bazel).

There are of course plenty of optimizations the JVM does that aren't possible AOT, but that that doesn't imply an automatic win at large scales, as Rust demonstrates.

pharrington• 2 months ago

Your Project Leyden's "AOT cache" Youtube link is broken, did you mean to link to https://www.youtube.com/watch?v=fiBNDT9r_4I?

layer8• 2 months ago

What do you mean by “control”?

ssiddharth• 2 months ago

Slight tangent, but every ms, μs, and ns counts too. We've gotten awfully carefree with response times and wasted compute cycles.

yas_hmaheshwari• 2 months ago

Out of course: I had thought about reading an article about Iran war or some geo political news when I read fzakaria :-)

pron24• 2 months 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-thc5• 2 months 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• 2 months ago

If the previous commenter won't say that, I will

Retr0id• 2 months 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.

pron24• 2 months 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.

LoganDark• 2 months ago

It doesn't take a "bad developer" to not consider the cost of every field...

perching_aix• 2 months ago

No, it means the opposite.

petra• 2 months ago

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

coolThingsFirst• 2 months ago

Why doesn’t the machine fill up the other cache lines as well why is 64 bytes only and then a miss?

masklinn• 2 months ago

They will absolutely do that (prefetching, they can even eagerly load what’s on the other side of a pointer).

However it requires additional hardware to recognize patterns which benefit from prefetching, and every time the CPU prefetches data which ends up not being used it has both burned energy and memory bandwidth, and evicted data from the cache which might be needed (cache pollution).

Liquid_Fire• 2 months ago

It might sometimes prefetch the surrounding lines as well, but ultimately cache space is limited, so there is a trade-off. Every time you fill a line, you are throwing away something else that was cached there previously, which you may need again in the near future.

spiffyk• 2 months ago

A cache line is simply the unit of data a CPU cache works with (generally 64 bytes, because someone somewhere has probably determined that that is the best line size for general use), much like there are units of data like bytes (8 bits nowadays, but there have been weird ones historically), pages (varies between hardware as well, and may be OS-configurable), etc.

As TFA mentions, a CPU does some predictions about what cache lines to prefetch, e.g. when you do sequential reads. Moreover, the x86_64 instruction set provides a prefetch instruction through which you are able to give the CPU a hint "hey, I'm gonna be using this soon, prepare accordingly, pretty please".

Still, the utility of prefetching is diminished if you only use a single byte from each cache line, because the mechanism generally depends on you doing other work while the next cache line is being fetched. So really the best case scenario is to take as much time as possible to work with what is already fetched, so that there is time for the next unit of data to be fetched in the meantime.

RickJWagner• 2 months ago

That’s a great read. I wish more people wrote like that.

fdegmecic• 2 months ago

CppCon 2014: Mike Acton "Data-Oriented Design and C++"

Andrew Kelley: A Practical Guide to Applying Data Oriented Design (DoD)

you should check these two talks out then.

lionkor• 2 months ago

The first is quite famous in data oriented design/programming circles, the second one is up there, too. Both very much worth watching.

setheron2• 2 months ago

(author) thank you for the kind words.

AxelWickman• 2 months ago

Cool read. The AoS vs SoA speaks for itself.

Luff• 2 months ago

Yes we should end the hateful rhetoric of most and least significant bytes. Every Byte Matters.

zabzonk• 2 months ago

We need an ending to byte-sizeism as well.

diabllicseagull• 2 months ago

We'll get there, bit by bit.

moi2388• 2 months ago

In combination with “What colour are your bits” I do not see this ending well..

moring• 2 months ago

The article shows nicely how "every byte matters" is false. First, it starts off by talking about the cost of a new field, when the actual topic is array-of-structs vs. struct-of-arrays. Then, this:

How much of an impact can this have? Reading is:alive (1 byte) Across 1M Monsters

You aren't reading one byte here, you are reading 1M bytes! Of course, optimizing the access to 1M bytes is something to consider. Optimizing the access to one byte isn't.

The article is definitely worth reading IMHO, but it really needs a better headline!

jayd166• 2 months ago

Even more so, it shows that SoA data structure means you can add fields to your 1M monsters with little impact.

celrod• 2 months ago

Yes. I think one of the big advantages of SoA is that you only pay for the fields you're currently using. If you need a field somewhere, you can add it and only pay the cost of iterating it where you need it.

notatyrannosaur• 2 months ago

you can add fields to your 1M monsters with little impact.

Great for this access pattern, but I wouldn't make a general statement like that. This is the same thing as row-oriented vs column-oriented databases, OLTP vs OLAP. SoA is weak if you are adding/removing monsters more often than accessing a single "hot" field.

gmueckl2• 2 months ago

This is valid for sequential scanning of the data. The CPU will fill whole cache lines at once with the arrays that do get used and the algorithm touches all the field instances in the array.

Now think about random access to single struct instances instead: the CPU loads a cache line worth of data for each field and uses only one element out of the whole cache line. This is much worse than a compact structure representation of the same data.

SoA is not universally better.

bronlund• 2 months ago

Every Struct Matters

burnt-resistor3• 2 months ago

I'm curious if anyone has had to write a JNI extension for a hot (CPU, GPU, RAM) section the JVM was unable to effectively JIT and/or optimize enough.

chadgpt34• 2 months ago

I think that's generally a pessimization because JNI has fairly high overhead.

burnt-resistor3• 2 months ago

So then, preferably the set of problems that take a long time to compute and does so independently.

nasretdinov• 2 months ago

Ideally you'd want to go further and actually store the is_alive as a bit mask and use SIMD instructions to filter out zeroes for example.

chadgpt34• 2 months ago

Even without SIMD (not counting SWIR as SIMD) if you knew most entities were alive, you could zoom through the array checking 64 at a time until you found one that wasn't all 1s and then inspect more closely. Though maybe an index list is better if they're almost all alive.

recursivedoubts• 2 months ago

When you are developing games, sometimes.

When you are developing most other applications every byte does not matter. What matters much more is overall system architecture, collapsing unnecessary abstraction layers that some developers (especially java developers) seem to love and optimizing your datastore access.

As always, profile profile profile.

A company I worked for spent a violent couple of man-decades flipping our proprietary scripting language from interpeted to bytecode generation, obviously with tons of bugs and subtle semantic changes, and it ended up boosting overall system performance by about 30%. We could have done nothing over that period of time and hardware advances would have made a bigger impact.

SuperV1234• 2 months ago

Data Oriented Design rocks. It was the subject for my CppCon 2025 keynote: https://youtube.com/watch?v=SzjJfKHygaQ

setheron2• 2 months ago

Add it to my watch list!

aapoalas• 2 months ago

Oh, I was just watching this yesterday and got a little re-energised about getting back to more active development of my DoD JS engine! Thanks!

rao-v4• 2 months ago

Anyways find it odd that major languages don’t have a built in way of asking for an array of objects to be optimized as SoA or AoS

jayd166• 2 months ago

It doesn't quite make sense to keep object identity at the language level. Inherently the data in the arrays cannot be the same memory of the data in the objects fields.

To get the speed up, you can't just abstract it as an access pattern because it's tied to the specific way the memory is laid out.

If you were trying to make some kind of collection type that could be queried by both row and column, you would need to store it both ways at all times and also keep both representations in sync, which also defeats the purpose, somewhat.

I feel like if you're trying to do this pattern then it doesn't make sense to also keep the objects.

chadgpt34• 2 months ago

Database structure in a programming language! I think I've heard this idea before but never seen it implemented. Define a table with rows and columns, give it some implementation hints and query it like "SELECT id FROM monsters WHERE alive=false" and the compiler could translate it several completely different ways depending on your layout.

rao-v4• 2 months ago

I was thinking about just asking the compiler to do the expensive reshuffle when I need it to, but you could go further and expect the compiler to figure out the likely access pattern and spend the transformation budget.

Heck memory is cheap (fine was cheap) give me a data structure that amortizes writes cleverly by maintaining both SoA and AoS at the same time

ChrisMarshallNY3• 2 months ago

I started off with Machine Code, on a device with 256 bytes (not KB) of RAM. That was 256 bytes, to install the executable, reserve the stack, and set up the heap.

We often used bit (not byte) fields, to convey information.

Made life challenging.

However, being able to be sloppy has its definite advantages. It takes a long time to design highly-optimized stuff. If just declaring a couple of new properties takes thirty seconds, and designing a bitfield takes an hour, then we have some real cost-savings, there.

That said, it's easy to get crazy, these days. I just spent a couple of days, chasing down greedy memory hogs. These were operations that ate gigabytes of memory. I determined that the real culprit was actually Apple MapKit, and figured out a simple workaround, but it took a long time to get there. If I suspect the OS, then it's usually my fault, and trying everything before going back to the OS takes time.

Obscurity43402• 2 months ago

How do you deal with all the daemons and automatic crap that does this on Mac? Isnt it all reinforced by SIP?

ChrisMarshallNY3• 2 months ago

I think all operating systems have these.

In this one case, allocating a MapView via storyboard, caused some kind of cascading strong reference stuff.

Simply allocating it programmatically, fixed it.

Took awhile to get there, though.

readthenotes1• 2 months ago

"In that time, you get used to huge classes. New functionality? Just add a new method and field to the class"

I guess this is one reason why object-orientation has such a bad reputation.

I once worked at a bank where the OO mentor had taught people that the only object they needed was "Tape" and have them replicate the structure of data on the old spooled tape reels.

The struct of arrays reminds me of this optimization.

compiler-guy• 2 months ago

SoA can be a big win. But so can plain AoS, just depends on the access pattern.

Profiling important workloads matters. Without that everything else is guesswork.

manoDev• 2 months ago

Tip: to get LN cache sizes on mac, the commmand is

    $ sysctl -a | grep "l.*cachesize" | gnumfmt --field=2 --to=si
    hw.perflevel1.l1icachesize:   132k
    hw.perflevel1.l1dcachesize:   66k
    hw.perflevel1.l2cachesize:    4,2M
    hw.perflevel0.l1icachesize:   197k
    hw.perflevel0.l1dcachesize:   132k
    hw.perflevel0.l2cachesize:      13M
    hw.l1icachesize:   132k
    hw.l1dcachesize:   66k
    hw.l2cachesize:    4,2M

And the equivalent to LEVEL1_DCACHE_LINESIZE is

    $ sysctl -a | grep hw.cachelinesize
    hw.cachelinesize: 128

agalunar• 2 months ago

Perhaps worth noting that the number of lines in a cache is often different than the number of rows, which can be relevant for some workloads.

The size of an ordinary cache is rows × ways × size(line), where rows = 2 ↑ num-idx-bits. For example, most Intel 64 and AMD 64 processors use log₂(size(page)) − log₂(size(line)) = 12 − 6 = 6 index bits for the L1 cache*, so an L1 cache with 8-way associativity is 64 sets × 8 lines/set × 64 bytes/line = 32 KB large, and an L1 cache with 12-way associativity is 64 × 12 × 64 = 48 KB large. I remember being surprised to learn that most processors have only 64 rows in the L1 cache!

*So that virtual indexes and physical indexes are identical (so that retrieval of the row can happen in parallel with TLB lookup).

jadbox• 2 months ago

Zig's MultiArrayList is a cool language feature to support objects of collections, and I wish more languages had first class support for it (without overhead of copy's).

PrathikArun• 2 months ago

Wow looks great!!!

johnthescott• 2 months ago

if truly "every byte matters" then why java?

Every Byte Matters

Related Stories