Initial port and addition of README.md #1
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
👍 Looks great! Thanks for the help. |
jaredpar
added a commit
that referenced
this pull request
Jan 14, 2015
Initial port and addition of README.md
tmat
added a commit
that referenced
this pull request
Feb 11, 2015
Build against alpha/experimental mdreader-vnext package
mattscheffer
added a commit
that referenced
this pull request
Mar 10, 2015
updating personal fork to latest commit
heejaechang
referenced
this pull request
in heejaechang/roslyn
May 5, 2015
…anges to delay solution crawler There are 2 things incremental processor takes care of @1 is making sure we delay processing any work until there is enough idle (ex, typing) in host. @2 is managing cancellation and pending works. we used to do #1 and #2 only for Roslyn files. and that is usually fine since most of time solution contains only roslyn files. but for mixed solution (ex, Roslyn files + HTML + JS + CSS), #2 still makes sense but #1 doesn't. We want to pause any work while something is going on in other project types as well. we need to make sure we play nice with neighbors as well. now, we don't care where changes are coming from. if there is any change in host, we puase oursevles for a while.
heejaechang
referenced
this pull request
in heejaechang/roslyn
Jun 2, 2015
this performance improvement is particularly for devdiv bug # 1089540 this makes the file in the bug to be formatted in several seconds compared to several minutes on my machine. there were several issues. each one fixed by #1, use concurrency on gathering operations. #2, don't use too much time to split work to chunks if that requires more work than actually formatting. #3, don't blindly set beginning of a file as inseparable start point for certain formatting options. ... but these don't actually address the most impactful root cause of this perf issues. which is perf issue of GetPrevious/GetNextToken API in compiler. (dotnet#3244) formatter internally uses GetDescendantTokens to get all tokens at once and cache them which takes less than 1 second for the entire file (2M bytes size) in the bug. and use the cache internally. but certain part of formatter (Rule Provider) can't use that internal cache, so it has to use the GetPrevious/GetNextToken to move around tokens, which in this particular bug, takes more than 40 seconds on my machine. and that is not even for entire file. (less than 1/12 of tokens) I opened a bug to compiler team, hopely so that we can get better perf on those APIs. in this PR, I mitigated the issue either by making more things to run concurrently or by changing logic which requires those APIs.
heejaechang
added a commit
that referenced
this pull request
Jun 4, 2015
make formatting performance better ... this performance improvement is particularly for devdiv bug # 1089540 this makes the file in the bug to be formatted in several seconds compared to several minutes on my machine. there were several issues. each one fixed by #1, use concurrency on gathering operations. #2, don't use too much time to split work to chunks if that requires more work than actually formatting. #3, don't blindly set beginning of a file as inseparable start point for certain formatting options. ... but these don't actually address the most impactful root cause of this perf issues. which is perf issue of GetPrevious/GetNextToken API in compiler. (#3244) formatter internally uses GetDescendantTokens to get all tokens at once and cache them which takes less than 1 second for the entire file (2M bytes size) in the bug. and use the cache internally. but certain part of formatter (Rule Provider) can't use that internal cache, so it has to use the GetPrevious/GetNextToken to move around tokens, which in this particular bug, takes more than 40 seconds on my machine. and that is not even for entire file. (less than 1/12 of tokens) I opened a bug to compiler team, hopely so that we can get better perf on those APIs. in this PR, I mitigated the issue either by making more things to run concurrently or by changing logic which requires those APIs.
This was referenced Nov 24, 2015
heejaechang
referenced
this pull request
in heejaechang/roslyn
Jan 22, 2016
experience seems actually quite better than before. anyway, 2 main changes are 1. active file analysis delay got shorten to 400ms from 800ms. 2. notification to editor on removed tags are now 50ms but added tags are now 1.5 seconds. ... more detail explanations below for #1. the delay change is only for 1 file (a file that has focus). all other file analysis delay is same as before (1.5 seconds). so I believe perf impact due to this should be fairly small. and it is still better than RTM which was 200ms. also, after RTM, we already made LB behavior not to be affected by this delay. so this change shouldn't affect LB behavior. for #2. tagger actually has many small delays in them. 2 main ones are 1) delay to produce tags 2) delay to notify editor about changed tags. 1) is to reduce doing repeated works to generate tags. for diagnostic tagger, this actually is not needed since unlike any other tagger, diagnostic tagger uses external service (diagnostic service) which already does all these things (basically #1 delay is logically doing what 1) is trying to do) now 1) delay is set to NearImmediate (50ms) 2) is to prevent us from abusing editors too much with a lot of notifications. basically this delay make sure we only ping editor once in a while (used to be 50ms) and aggregate events between them. now, 2) is split into 2 different delays. one for adding new tags and the other for removing old tags. adding new tags is now set to 1.5 seconds and removing old tags is set to 50ms.
heejaechang
added a commit
that referenced
this pull request
Apr 14, 2016
OOP #1 - new analyzer engine that uses CompilerAnalyzer model
agocke
added a commit
that referenced
this pull request
Apr 22, 2016
Revert "Add support for calling local functions with dynamic args (#1…
genlu
added a commit
that referenced
this pull request
Feb 12, 2022
The computation of completion items is divided into two tasks: 1. "Core" items(i.e.non - expanded) which should be included in the list regardless of the selection of expander. Right now this includes all items except those from unimported namespaces. 2 .Expanded items which only show in the completion list when expander is selected, or by default if the corresponding features are enabled. Right now only items from unimported namespaces are associated with expander. #1 is the essence of completion so we'd always wait until its task is completed and return the results. However, because we have a really tight perf budget in completion, and computing those items in #2 could be expensive especially in a large solution (e.g.requires syntax / symbol indices and/ or runs in OOP,) we decide to kick off the computation in parallel when completion is triggered, but only include its results if it's completed by the time task #1 is completed, otherwise we don't wait on it and just return items from #1 immediately. Task #2 will still be running in the background (until session is dismissed/committed,) and we'd check back to see if it's completed whenever we have a chance to update the completion list, i.e.when user typed another character, a filter was selected, etc. If so, those items will be added as part of the refresh. The reason of adopting this approach is we want to minimize typing delays. There are two ways user might perceive a delay in typing. First, they could see a delay between typing a character and completion list being displayed if they want to examine the items available. Second, they might be typing continuously w/ o paying attention to completion list, and simply expect the completion to do the "right thing" when a commit char is typed(e.g.commit "cancellationToken" when typing 'can$TAB$'). However, the commit could be delayed if completion is still waiting on the computation of all available items, which manifests as UI delays and in worst case timeouts in commit which results in unexpected behavior(e.g.typing 'can$TAB$' results in a 250ms UI freeze and still ends up with "can" instead of "cancellationToken".) This approach would ensure the computation of #2 will not be the cause of such delays, with the obvious trade off of potentially not providing expanded items until later(or never) in a completion session even if the feature is enabled.Note that in most cases we'd expect task #2 to finish in time and complete result would be available from the start of the session.However, even in the case only partial result is returned at the start, we still believe this is acceptable given how critical perf is in typing scenario. Additionally, expanded items are usually considered complementary. The need for them only rise occasionally(it's rare when users need to add imports,) and when they are needed, our hypothesis is because of their more intrusive nature(adding an import to the document) users would more likely to contemplate such action thus typing slower before commit and / or spending more time examining the list, which give us some opportunities to still provide those items later before they are truly required. In this commit we have to handle adding those delayed expanded items into completion list in Roslyn. This is because the `CompletionContext.IsIncomplete` flag isn't fully supported in classic mode. Will need to move to that API once it's implemented properly.
Cosifne
pushed a commit
that referenced
this pull request
Mar 30, 2024
Track the telemetry of rename
Merged
davidwengier
pushed a commit
that referenced
this pull request
Oct 18, 2024
…tionAPI Access services on Solution rather than Workspace
This was referenced Oct 22, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a port of the readme from CodePlex. Some of the links have been updated to point to locations on GitHub, but many of the links still point back to CodePlex as comparable GitHub locations are currently absent.