Почему StringBuilder не может удерживать огромные строки и генерировать исключение OOM

Question

Я конвертирую строку HTML в PDF с помощью iTextSharp XMLWorker. Раньше это работало нормально и генерировало хорошие файлы pdf, но позже я добавил изображения строки base64 в строку My HTML, которую я хочу показать в моем PDF. он отлично работает для нескольких изображений (небольшая строка), но когда количество изображений увеличивается параллельно, размер строки увеличивается. Я возвращаю строку HTML из такой функции, как эта

sb = new StringBuilder();
tw = new StringWriter(sb);
hw = new HtmlTextWriter(tw);
tblDistrictwiseResults.RenderControl(hw);
return sb.ToString();

, и теперь возвращенная строка HTML добавляется к другой строке, как показано ниже

StringBuilder sb = new StringBuilder();

sbFooter = new StringBuilder();
tw = new StringWriter(sbFooter);
hw = new HtmlTextWriter(tw);
tblFooter.RenderControl(hw);


string pdfString = GetPDFString(paperCode, paperName, true);  //This is the string returned from anothe function
sb.Append(pdfString + "<br />" + sbFooter.ToString()); //concatinating returned string and footer string and saving in another stringbuilder( here I am gettiong OOM Exception )

, и строка становится очень большой но он не превысил максимальную емкость StringBuilder.

Пожалуйста, помогите мне

РЕДАКТИРОВАТЬ: Я использую VS2010 (32-разрядный) и 32-разрядный сервер DEV

Answer 1

. NET имеет ограничения памяти в зависимости от того, в какой двоичной системе вы работаете. А те, которые на лиг меньше ограничений ОС, не напоминайте об аппаратных ограничениях: https://docs.microsoft.com/en-us/windows/win32/memory/memory-limits-for-windows-releases

Плюс ограничение на объект 2 ГиБ. И строки или массивы (которые, как я полагаю, использует построитель строк) выходят за пределы размера объекта или памяти, как известно, быстро.

По умолчанию all. NET code - это битность c. Тот же код может работать как x32 или x64 - или даже x16 или x128, если мы когда-нибудь получим для этого среду выполнения. Исправление процесса, работающего только на двоичной системе x64, может решить немедленную проблему. Однако более серьезной проблемой является сам процесс :

Строки легко могут нарушить ограничения памяти. Но они ничего не нашли на изображениях. Изображения огромные! Это книжный пример для BLOB - Binary Large OBject - страшно хранить в памяти.

Кодировка Base64 делает их примерно на 33% больше. Если вы затем попытаетесь сохранить в памяти целый PDF-документ с такими гигантскими строками, вы можете столкнуться только с проблемами. Это чудо, что это сработало до сих пор. Вам нужно изменить свой процесс, чтобы в памяти были строки меньшего размера. Что на самом деле может означать намного меньше конкатенации, что может даже сделать недействительным необходимость использования StringBuilder в первую очередь.