Too much string.Concat in generated code with large blocks of HTML #614
Comments
|
I'm surprised that this is using |
|
For example, this code: var x = "a" + "b";
Console.WriteLine(x);Compiled into this (via ILSpy): string value = "ab";
Console.WriteLine(value);And similar code is in the IL: |
|
I tried with strings that add up to ~300KB and I got the same results each time: all the string literals were folded (feld? felled? felded? follied?) into one giant string. The form of my strings was the same as in the example: var x =
"p>Paragraph</p><p>Paragraph</p><p>Paragraph</p><p>Paragraph</p><p>Paragraph</p><" +
"p>Paragraph</p><p>Paragraph</p><p>Paragraph</p><p>Paragraph</p><p>Paragraph</p><" +
... |
|
Per @NTaylorMullen - this semantic was copied from CodeDOM, and was intended to avoid an LOH allocation. It doesn't sound like that's doing what it's supposed to do. We might need to measure more to see what's better for GC perf here - allowing the LOH string vs breaking it up into separate writes. Ok with pushing this item out until we're in a better position to test this. |
|
My only point was there there's no |
|
Yeah, you're totes bringing the pain. We should still look at this though. |
|
@Eilon @NTaylorMullen - this causes an OOM sometimes during runtime compilation: We need to split this up into smaller chunks |
|
@rynowak should we also be filing a Roslyn bug? The memory quantities in play here are not really that much. A few hundred KB is a drop in the bucket even in a 32bit process. |
|
DerpI think I'll go file that bug now.
|
|
Nice memory stress test 😄 |
|
This is actually known and also happens when we implemented the roslyn codedom based compiler. /cc @DamianEdwards |
|
It's pretty obviously known since there's a bug. Are you trying to make another point? We need to fix this. |
|
That we brought it up with the roslyn team back then and I believe the answer was to compile out of process to avoid bringing down the server with an OOM. I'm not sure there was a real solution per se. |
|
But the OOM would happen anyway, no? I mean, something somewhere is going to get an OOM and compilation will fail. Don't care which process is crashing, my app doesn't work. But either way we're going to need to avoid this problem in Razor so it's not as big an issue for us. |
|
The difference can be that one view/page fails to compile vs. the entire app. |
|
Razor needs to break up long literals every X chars and call I think the only question is what "X" should be. 1KB? 10KB? 50KB? |
|
Could solve this bug by moving a special case from See Most (Side note: |
- Roslyn currently has an issue where too large of strings result in out of memory exceptions at compile time. To combat this I broke down literal strings into 1k pieces each resulting in their own `WriteLiteral`/`WriteLiteralTo` calls. - Added tests to validate large string rendering. #614
- Roslyn currently has an issue where too large of strings result in out of memory exceptions at compile time. To combat this I broke down literal strings into 1024 length pieces each resulting in their own `WriteLiteral`/`WriteLiteralTo` calls. The 1024 number corresponds directly with MVCs response string buffer. - Added tests to validate large string rendering. #614
Take a gander at the generated code for a page with a lot of 'literal text'
https://github.com/rynowak/mvc-sandbox/blob/master/workloads/RazorCodeGenerator/LargePage.cshtml
Yeah, that's a
string.Concatthat's going to make a 160056 character string.We need to make Razor smarter.
The text was updated successfully, but these errors were encountered: