Skip to content
This repository was archived by the owner on Jan 23, 2023. It is now read-only.

Remove lazy initialization of Task.CompletedTask#8846

Merged
stephentoub merged 2 commits intodotnet:masterfrom
stephentoub:completedtask
Jan 8, 2017
Merged

Remove lazy initialization of Task.CompletedTask#8846
stephentoub merged 2 commits intodotnet:masterfrom
stephentoub:completedtask

Conversation

@stephentoub
Copy link
Member

The lazy-initialization code of Task.CompletedTask is causing it to be an "unprofitable inline". For workloads that make heavy use of Task-returning methods that complete synchronously, this is showing up as a measurable impact, e.g. in a simple benchmark reading and writing to the channels in the channels lib on corefxlabs, it's resulting in 2-5% overhead. However, as it's used by a bunch of core .NET types, e.g. a bunch of streams like FileStream and MemoryStream, it's rare that it won't be needed, and it's often needed very early in a program's execution. This commit just removes the lazy-initialization, removing a branch and allowing the getter to be inlined.

cc: @jkotas, @AndyAyersMS

The lazy-initialization code of Task.CompletedTask is causing it to be an "unprofitable inline".  For workloads that make heavy use of Task-returning methods that complete synchronously, this is showing up as a measurable impact, e.g. in a simple benchmark reading and writing to the channels in the channels lib on corefxlabs, it's resulting in 2-5% overhead.  However, as it's used by a bunch of core .NET types, e.g. a bunch of streams like FileStream and MemoryStream, it's rare that it won't be needed, and it's often needed very early in a program's execution.  This commit just removes the lazy-initialization, removing a branch and allowing the getter to be inlined.
@sharwell
Copy link

sharwell commented Jan 8, 2017

Based on #1157 leading to #4340, I'm not seeing a downside here.

@@ -1617,21 +1617,8 @@ internal TaskScheduler ExecutingTaskScheduler
/// </remarks>
public static TaskFactory Factory { get { return s_factory; } }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit - it may be nice to change this one to use the same syntax as CompletedTask to make the style locally consistent.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

@benaadams
Copy link
Member

Interesting; always wondered why it showed up on traces - never thought to look though.

@benaadams
Copy link
Member

Upstream workarounds TaskCache - though also deal with the missing api in NET451

@stephentoub
Copy link
Member Author

@jkotas, shall I port this to corert, or is there any reason to keep it lazy there? (I ask because it looks like the TaskFactory property there was made lazy in the port to .NET Native / corert.)

@stephentoub stephentoub merged commit c586863 into dotnet:master Jan 8, 2017
@stephentoub stephentoub deleted the completedtask branch January 8, 2017 18:25
@jkotas
Copy link
Member

jkotas commented Jan 8, 2017

Yes, I think it should be ported to CoreRT. I do not think there is a good reason for CoreRT to differ for these two properties.

The TaskFactory laziness was introduced as part of some AOT binary size micro-optimizations in early days of .NET Native. I do not think these micro-optimizations are good in this case. They trade small binary size gain in some cases for measurable throughput loss.

manofstick pushed a commit to manofstick/coreclr that referenced this pull request Jan 16, 2017
Remove lazy initialization of Task.CompletedTask
@karelz karelz modified the milestone: 2.0.0 Aug 28, 2017
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
Remove lazy initialization of Task.CompletedTask

Commit migrated from dotnet/coreclr@c586863
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants