Avoid memory allocation and improve performance, part 1 by DaniilSokolyuk · Pull Request #522 · reactjs/React.NET

DaniilSokolyuk · 2018-03-24T15:22:19Z

Hi @Daniel15, for more than a year we have been using this library, and recently noticed problems with allocations and object hits in Large Object Heap if the component is large or a large props is serialized

Goals

Native implementation for IHtmlString without recopy and allocating new strings
Reuse everything
ComponentExistsChecks configuration property (default true), for disable "EnsureComponentExists" (avoid extra engine call, in production for example)

Branch with banchmarks here https://github.com/DaniilSokolyuk/React.NET/tree/bench
Note the difference between the nano seconds and microseconds

Before, Small objects

Method	Mean	Error	StdDev	Gen 0	Gen 1	Allocated
CreateComponent	12.97 us	0.0954 us	0.0845 us	1.8463	0.5035	10.9 KB
React	17.19 us	0.2015 us	0.1787 us	7.8430	1.1597	43.81 KB
ReactInitJavaScript	75.81 us	0.5654 us	0.5012 us	146.9727	-	602.56 KB

After, Small objects

Method	Mean	Error	StdDev	Gen 0	Gen 1	Allocated
CreateComponent	541.4 ns	10.55 ns	10.83 ns	0.0496	0.0143	312 B
React	12,973.0 ns	119.90 ns	100.12 ns	1.8005	0.4883	11320 B
ReactInitJavaScript	11,401.2 ns	72.78 ns	64.52 ns	0.1831	-	792 B

Before, Large objects

Method	Mean	Error	StdDev	Gen 0	Gen 1	Gen 2	Allocated
CreateComponent	35.76 us	0.2885 us	0.2558 us	5.6763	1.5259	-	34.8 KB
React	48.16 us	0.4108 us	0.3843 us	24.7803	3.5400	-	139.08 KB
ReactInitJavaScript	417.16 us	4.9953 us	4.6726 us	356.4453	142.5781	71.2891	1980.55 KB

After, Large objects

Method	Mean	Error	StdDev	Gen 0	Gen 1	Allocated
CreateComponent	551.0 ns	10.95 ns	9.710 ns	0.0496	0.0143	312 B
React	36,337.2 ns	130.36 ns	121.939 ns	5.0049	1.3428	31585 B
ReactInitJavaScript	51,691.7 ns	766.71 ns	717.185 ns	24.8413	0.5493	104398 B

dustinsoftware · 2018-03-24T15:28:16Z

Thanks for starting this conversation. It looks like there are a few breaking changes (like making component disposable), which could be a problem. This PR is also quite large, it would be better to split up optimization’s into smaller PRs so we can discuss each change :)

Otherwise as is it’s going to be a bit before we can work through this one.

DaniilSokolyuk · 2018-03-24T15:33:21Z

@dustinsoftware i think disposable component is the smallest problem :)
I do not think that there are so many changes here, backward compatibility is also completely left, I do not consider it necessary to split pr

Daniel15 · 2018-03-24T23:30:01Z

This is probably the largest pull request we've ever received :) Thanks for working on it.

There's a lot of changes that change #if NET40 to #if NET40 || NET451, is it possible to split those out into a separate pull request? As @dustinsoftware said, it's much easier to review multiple small PRs instead of one giant one.

DaniilSokolyuk · 2018-03-25T06:47:26Z

@Daniel15 Thanks you, splitted, after this PR I will create another PR

DaniilSokolyuk · 2018-03-28T19:07:55Z

@Daniel15, @dustinsoftware what about this PR? I have already split this request and prepared the
second part
We are already using these changes and significantly reduced the hits in LOH and FullGC

dustinsoftware · 2018-03-28T19:10:21Z

When you’re ready, please open some smaller pull requests so that we can review and merge those changes individually :)

…

On Wed, Mar 28, 2018 at 12:08, Daniil Sokolyuk ***@***.***> wrote: @Daniel15 <https://github.com/Daniel15>, @dustinsoftware <https://github.com/dustinsoftware> what about this PR? I have already split this request and prepared the second part <https://github.com/DaniilSokolyuk/React.NET/tree/avoid-memory-allocations-part2> We are already using these changes and significantly reduced the hits in LOH and FullGC — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#522 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA5hFmwUqVYqIUKtOtV4BGc4NSQPnk2dks5ti9-OgaJpZM4S5xkt> .

DaniilSokolyuk · 2018-03-28T19:13:53Z

@dustinsoftware i am already split this PR, there are only 227 new lines here, and about 60% this lines is replace string.format to TextWriter.Write

dustinsoftware

Thanks for submitting this PR! There are some good changes in here but we'll need to break this up into separate PR's even further before we can continue (if you don't have time to do that, let us know, and we can pick out some of these changes and test them individually when we have time).

From what I could tell, there are five separate improvements here:

Use new component ID generation instead of Guid.NewGuid
Using StringBuilder/TextWriter instead of string.Format to generate HTML
Cache component name validation
Optionally skip component exists checks
Update JSON.NET version

With each of these improvements it would be great to see how much these changes affected the benchmarks instead of testing all of them at once. It could be that some of these changes made a significant difference (such as using StringBuilder) and others not so much (such as changing how IDs are generated).

Let me know if you'd like some more clarification or help moving this PR forward!

dustinsoftware · 2018-04-07T16:16:49Z

src/React.AspNet/HtmlHelperExtensions.cs

 			{
-				tag.Attributes.Add("nonce", Environment.Configuration.ScriptNonceProvider());
+				writer.Write(" nonce=\"");
+				writer.Write(Environment.Configuration.ScriptNonceProvider());


I see that we're manually constructing HTML tags in existing code.. as long as we're not passing user-generated data to these methods, this should be OK (although it would be nice to sanitize the data going into these attributes just in case)

yea, original tag builder has a similar code https://github.com/aspnet/Mvc/blob/feed0fea2c5280264ac000947b3fee542d7d9e6a/src/Microsoft.AspNetCore.Mvc.ViewFeatures/Rendering/TagBuilder.cs#L336

dustinsoftware · 2018-04-07T16:18:02Z

src/React.Core/React.Core.csproj

    <PackageReference Include="JSPool" Version="3.0.1" />
    <PackageReference Include="MsieJavaScriptEngine" Version="2.2.2" />
-    <PackageReference Include="Newtonsoft.Json" Version="9.0.1" />
+    <PackageReference Include="Newtonsoft.Json" Version="10.0.3" />


Is bumping Json.NET required for this PR?

No, split PR fail, bumping JSON.NET need in part 2 for use ArrayPool, fixed

dustinsoftware · 2018-04-07T16:20:20Z

src/React.Core/ReactComponent.cs

 		/// <param name="exceptionHandler">A custom exception handler that will be called if a component throws during a render. Args: (Exception ex, string componentName, string containerId)</param>
 		/// <returns>HTML</returns>
-		public virtual string RenderHtml(bool renderContainerOnly = false, bool renderServerOnly = false, Action<Exception, string, string> exceptionHandler = null)
+		public string RenderHtml(bool renderContainerOnly = false, bool renderServerOnly = false, Action<Exception, string, string> exceptionHandler = null)


Removing virtual is a breaking change, can this be avoided?

we can return virtual but it does not make sense and can cause errors
because all methods and extensions uses overload with textwriter

dustinsoftware · 2018-04-07T16:24:16Z

src/React.Core/ReactComponent.cs

 		{
-			var isValid = componentName.Split('.').All(segment => _identifierRegex.IsMatch(segment));
-			if (!isValid)
+			//TODO: cache


Let's remove any TODOs before merging this in

dustinsoftware · 2018-04-07T16:30:12Z

src/React.Core/ReactComponent.cs

-						? string.Format("ReactDOMServer.renderToStaticMarkup({0})", GetComponentInitialiser())
-						: string.Format("ReactDOMServer.renderToString({0})", GetComponentInitialiser());
-					html = _environment.Execute<string>(reactRenderCommand);
+					stringWriter.Write(renderServerOnly ? "ReactDOMServer.renderToStaticMarkup(" : "ReactDOMServer.renderToString(");


This doesn't look thread safe - multiple threads could call Write at the same time to this shared instance. Keeping StringWriter scoped to this method instead of using a static field would solve this.

_sharedStringWriter is marked as ThreadStatic and this is unique for each thread. (corefx use similar strategy, https://github.com/dotnet/corefx/blob/master/src/Common/src/System/IO/StringBuilderCache.cs) , I am reuse evertything for reduce allocations.

Oh ok, did not know about ‘ThreadStatic’ :)

DaniilSokolyuk · 2018-04-07T17:24:28Z

@dustinsoftware, yes you right, but previous ID generating is ugly, we are allocate GUID, after allocate byte array and 1-3 string... my implementation used 1 string,
removed Json.NET bump

dustinsoftware · 2018-04-07T21:45:12Z

src/React.Core/ReactComponent.cs

 			var html = string.Empty;
 			if (!renderContainerOnly)
 			{
+				var stringWriter = _sharedStringWriter;


This variable declaration is unnecessary - you can just use _sharedStringWriter here and below:

if (_sharedStringWriter == null) _sharedStringWriter = new StringWriter(new StringBuilder(512));

Also, the Write method on StringWriter just calls the wrapped StringBuilder, so it would be better to just use StringBuilder.

This variable is not unnecessary, because access to ThreadStatic variable is slow http://tips.x-tensive.com/2008/10/cost-of-threadstatic-attribute.html

StringBuilder is not implement TextWriter, we cant use StringBuilder

dustinsoftware · 2018-04-07T21:58:45Z

src/React.Core/ReactComponent.cs

+				{
+					_sharedStringWriter = 
+						stringWriter = 
+						new StringWriter(new StringBuilder(512));


This number seems unnecessarily large and might allocate more space than necessary for simple components, let's leave it unset unless there is a noticeable benefit to specifying a large value

In part 2 i will remove all the StringWriter, StringBuilders and threadStatic and replace them with my own buffer based on ArrayPool, https://github.com/DaniilSokolyuk/React.NET/blob/c271afeb369875194a31c18bbbe6b76fac947d51/src/React.Core/ReactComponent.cs#L150

dustinsoftware · 2018-04-07T22:16:01Z

previous ID generating is ugly

There may be consuming code that depends on the current ID format, so this isn't a good reason to change it. We unfortunately don't know how consumers are using this project and want to avoid surprises between version updates.

Daniel15 · 2018-04-08T00:49:53Z

Thanks for reviewing this, @dustinsoftware!

DaniilSokolyuk · 2018-04-08T07:08:53Z

@dustinsoftware , we can announce this change or publish major version

dustinsoftware · 2018-04-08T14:28:16Z

That’s not the point I was trying to make... I am hesitant to merge in changes for minor improvements that are technically breaking changes.

The discussion on this PR is getting too long, please open a new one for each individual change (such as ones the bulleted list above) and we can discuss them one at a time :)

DaniilSokolyuk force-pushed the avoid-memory-allocation branch from 1cc32fb to 3b5e5c9 Compare March 24, 2018 16:58

DaniilSokolyuk changed the title ~~[WIP] Avoid memory allocation and improve performance~~ Avoid memory allocation and improve performance Mar 24, 2018

DaniilSokolyuk force-pushed the avoid-memory-allocation branch from bbffdde to 60d96bb Compare March 25, 2018 06:45

DaniilSokolyuk changed the title ~~Avoid memory allocation and improve performance~~ Avoid memory allocation and improve performance, part 1 Mar 25, 2018

Avoid memory allocations

bdda3e6

DaniilSokolyuk force-pushed the avoid-memory-allocation branch from 60d96bb to bdda3e6 Compare March 29, 2018 12:03

dustinsoftware requested changes Apr 7, 2018

View reviewed changes

review fixes

67e3aae

dustinsoftware reviewed Apr 7, 2018

View reviewed changes

dustinsoftware closed this Apr 8, 2018

This was referenced Apr 9, 2018

Native IHtmlContent/IHtmlString implementation #527

Merged

Avoid large objects allocations and reuse everthing #532

Merged

Daniel15 mentioned this pull request Dec 31, 2020

Use of [ThreadStatic] in ReactComponent #1235

Open

Conversation

DaniilSokolyuk commented Mar 24, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dustinsoftware commented Mar 24, 2018

Uh oh!

DaniilSokolyuk commented Mar 24, 2018

Uh oh!

Daniel15 commented Mar 24, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DaniilSokolyuk commented Mar 25, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DaniilSokolyuk commented Mar 28, 2018

Uh oh!

dustinsoftware commented Mar 28, 2018 via email

Uh oh!

DaniilSokolyuk commented Mar 28, 2018

Uh oh!

dustinsoftware left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DaniilSokolyuk Apr 7, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DaniilSokolyuk Apr 7, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DaniilSokolyuk commented Apr 7, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DaniilSokolyuk Apr 8, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dustinsoftware commented Apr 7, 2018

Uh oh!

Daniel15 commented Apr 8, 2018

Uh oh!

DaniilSokolyuk commented Apr 8, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dustinsoftware commented Apr 8, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

DaniilSokolyuk commented Mar 24, 2018 •

edited

Loading

Daniel15 commented Mar 24, 2018 •

edited

Loading

DaniilSokolyuk commented Mar 25, 2018 •

edited

Loading

DaniilSokolyuk Apr 7, 2018 •

edited

Loading

DaniilSokolyuk Apr 7, 2018 •

edited

Loading

DaniilSokolyuk commented Apr 7, 2018 •

edited

Loading

DaniilSokolyuk Apr 8, 2018 •

edited

Loading

DaniilSokolyuk commented Apr 8, 2018 •

edited

Loading