Entity Framework Core: Default Comparer For Byte Arrays May Waste Lots Of Memory And CPU

The default implementation of Entity Framework Core prefers to play it safe (for good reasons) when working with byte arrays. This 'safety' is - in some use cases - unnecessary and costs us a lot of memory and CPU. In this article, we will see that doing less is sufficient for the given property thanks to one of the most overlooked features of Entity Framework.

In this article:

Pawel Gerr is architect consultant at Thinktecture. He focuses on backends with .NET Core and knows Entity Framework inside out.

Please note: this article is not about whether a byte array should or should not be used with relational databases but rather about “if you do, then be aware of …”

EF's default behavior with byte arrays

When working with byte arrays and change tracking is active, then on SaveChanges Entity Framework Core (EF) is not just comparing the object references of the arrays, but the content as well. If the corresponding property represents some kind of bit-mask, i.e., every byte in the array is changed independently, then comparing every byte is necessary. But, most of the time, I see in projects that the properties are used for persisting small binary data, like thumbnails, which are considered immutable. In such cases, it is unlikely that someone will change single bytes inside the array. If the thumbnail has to be changed, then the byte array is replaced by another byte array, i.e., the new one is a completely new object reference.

How much does it cost?

Having some binary data, the comparison of the content is not wrong in general but unnecessary. I’ve benchmarked a few use cases in terms of memory and CPU usage. One entity was using the default behavior, the other a custom ValueComparer.

The benchmarks update 10k entities with 1kB array each. Before calling SaveChanges, the property is assigned one of two new arrays. One new array has 1 different byte at the beginning and is considered the best-case, and the other has a different byte at the end of the array.

					// array read from database = [0,0,0,...,0];

var newArray_bestCase = [1,0,0,...,0];
var newArray_worstCase = [0,0,0,...,1];

All benchmarks do two things: update the property bytes and call SaveChanges.

					entitiesLoadedFromDb.ForEach(e => e.Bytes = newArray_bestCase); // or newArray_worstCase

await myDbContext.SaveChangesAsync();

For benchmarking, I use the library BenchmarkDotNet with the MemoryDiagnoser.

The source code can be found on GitHub

					|            Method |       Mean |    Error |   StdDev | Gen 0 |Gen 1 | Allocated |
|------------------ |-----------:|---------:|---------:|------:|-----:|----------:|
|  Default_BestCase |   337.0 ms |  4.01 ms |  3.75 ms |  7000 | 2000 |     63 MB |
| Default_WorstCase | 1,220.7 ms | 11.84 ms | 11.07 ms | 66000 | 2000 |    531 MB |
|   Custom_BestCase |   325.6 ms |  6.16 ms |  5.46 ms |  8000 | 2000 |     65 MB |
|  Custom_WorstCase |   330.5 ms |  5.02 ms |  4.70 ms |  8000 | 2000 |     65 MB |

Worst case, the memory usage rises from 63 MB to 531 MB (ca. 850%) and the duration from 337 ms to 1220 ms (over 350%), when using the default behavior. With the custom ValueComparer, the values always staylow.

Use reference equality for opaque binary data

The ValueComparer can be changed in OnModelCreating or in IEntityTypeConfiguration<T> via the method SetValueComparer. The method expects an instance of ValueComparer, which can be implemented from scratch or by using the generic class ValueComparer<T>. The constructor of ValueComparer<T> expects three expressions:

  • equalsExpression: compares two instances using reference equality
  • hashCodeExpression: computes the hash code
  • snapshotExpression: passes the reference of the array as is because it is enough for reference equality
					builder.Property(e => e.Bytes)
       .SetValueComparer(new ValueComparer<byte[]>(
            (obj, otherObj) => ReferenceEquals(obj, otherObj),
            obj => obj.GetHashCode(),
            obj => obj));


In this article, we looked at the ValueComparer and how it affects memory and CPU usage when using byte arrays with EF. Although we were talking about byte arrays only, the same performance issues could arise with all custom objects with a ValueConverter (please note: Converter, not Comparer).


Current articles, screencasts and interviews by our experts

Don’t miss any content on Angular, .NET Core, Blazor, Azure, and Kubernetes and sign up for our free monthly dev newsletter.

EN Newsletter Anmeldung (#7)
Related Articles
One of the more pragmatic ways to get going on the current AI hype, and to get some value out of it, is by leveraging semantic search. This is, in itself, a relatively simple concept: You have a bunch of documents and want to find the correct one based on a given query. The semantic part now allows you to find the correct document based on the meaning of its contents, in contrast to simply finding words or parts of words in it like we usually do with lexical search. In our last projects, we gathered some experience with search bots, and with this article, I'd love to share our insights with you.
If you previously wanted to integrate view transitions into your Angular application, this was only possible in a very cumbersome way that needed a lot of detailed knowledge about Angular internals. Now, Angular 17 introduced a feature to integrate the View Transition API with the router. In this two-part series, we will look at how to leverage the feature for route transitions and how we could use it for single-page animations.
.NET 8 brings Native AOT to ASP.NET Core, but many frameworks and libraries rely on unbound reflection internally and thus cannot support this scenario yet. This is true for ORMs, too: EF Core and Dapper will only bring full support for Native AOT in later releases. In this post, we will implement a database access layer with Sessions using the Humble Object pattern to get a similar developer experience. We will use Npgsql as a plain ADO.NET provider targeting PostgreSQL.