Just a quick one today. One of the joys of being a software developer is that it’s a constant learning experience, even after 20+ years in the field, I’m still learning something new on, at least, a weekly basis.
Today, whilst combing through some error logs to find the root of an OutOfMemoryException, I found the cause to be none other than that old hero: StringBuilder, which led me to wonder about it’s limitations: “String Builders don’t have limits.”, I confidently scoffed. Only to have a moment of doubt and a quick google for the documentation and here’s what I learned today …
And lo and behold, StringBuilders do indeed have limitations, which makes perfect sense when you really sit back to think of it. The limitation in earlier .Net (implementations is enforced by the MaxCapacity property of the class, which is an Int32, i.e. around 2.1bn bytes. On a side-note, Microsoft Documentation indicates that versions of .Net will allow you to overflow this using .Append().
But of course a chain is only as weak as its weakest link, there’s a beautiful answer on Stack Overflow from Eric Lippert, explaining that you only get 2Gb of user-addressable virtual address space per process on a 32 bit Windows machine.
So onto the next link in our chain; “Where are we running?”. Which in turn finally leads us to our breaking point, this particular software is running in a Kubernetes Pod and is actually constrained in it’s memory by very design, after all you don’t want a run-away pod to consume all of the available resources in your cluster right? In this case, our pod was limited to a very generous 1Gb.
A StringBuilder has limits but you’re almost certainly going to bump into other limits before you even come close, and frankly if you’ve got a StringBuilder running at capacity, you’re almost certainly doing it wrong in the first place.
In this case, I fixed the bug by validating my input to prevent a stupidly large date range. Problem Solved!
Jarrett Solutions 