Performance issue

Hi Tobias,

For complex scenarios like this, it would be best if you can write our support address with a new simple sample project that shows the issue.  Then we can debug with that to see what's going on, and if there is a problem.  If you send something over, please reference this thread and remove the bin/obj folders from the .zip you send so it doesn't get spam blocked.

I don't believe the logic is necessarily wrong there, since snapshotRange is constructed above that point (originally based on desiredSnapshotRange) and is what all subsequent code is using.  Having a sample project to reproduce will help us validate the logic and better assess how the code you identified might be improved and/or corrected.

Note that document snapshots do not store the tokens associated with them.  We made that decision since doing so would consume a LOT of extra memory considering multiple immutable snapshots can be live at any given time.  Instead, tokens are lexed on the fly as needed.

I see. I resolved the issue by adding a cache which stores the ITypeDefinition result for a given IQualifiedName. Since most types are system-defined like Object or Int32, this is quite effective.

The problem has re-emerged after we realized that the IQualifiedName not always resolves to the same symbol...

The performance issue is huge in big projects. I have a customer project were the resolution alone takes 6 minutes for the complete project.

Since we are close to the next release, I am looking for any straw that has a significant performance impact. Is there anything we can do to speed up the lexer process or avoid it all together? I tried to initialize the tokens after the semantic parser is finished, but it didn't work.

I will try to parallelize the process, but thats a bit tricky and even with eight cores it takes too long.

Hello,

Can you get into some overview detail of what you're trying to achieve in general?  It sounds like you have a project assembly with many files in it (how many?), and you are perhaps trying to run your ResolveTypeDefinition method  multiple times in each document.  Are you trying to resolve identifiers in your unloaded documents to type definitions, or something else?

A summary of what the intent of all this is and how things are structured would help us reply more effectively.  And as always, it's best to submit a new simple sample project that shows the issue occurring so that we can debug with it and see what you see.  Thank you!

Well basically we generate from all source files an extract that contains information about all functions. Background of this is that we support multiple languages and editors that can interact with each other. So C# is just one of those and we use the data to display and validate what functions can be called from the other editors. And obviously we need to account all files, not just those that are opened in an editor.

In that particular case we use ResolveTypeDefinition() to get the referenced type and check if it is an enum. If so we need to get the members of the enum. So this is called for every time a user-defined type is used as a parameter or return type, per function, per file, per project assembly. In this case 62 C# files are all used in 35 project assemblies (so 62 * 35). With the cache this sums up to almost 5.000 calls of ResolveTypeDefinition(). So yeah, thats a lot, but what takes so long is not the actual resolve operation, but the lexical parsing when the context is created.

To summarize, I currently see no way we could reduce the number of calls. It looks like the document is lexed in each resolve call, which is totaly unecessary. I get that you no longer store the tokens to save memory, but I think in my case an option would be great to keep the tokens in memory. Especially since my documents are mostly offline (not open in an editor) and therefore are not constantly changed. If the memory consumption gets to accessive, the developer could reset the option (e.g. in ICodeDocument).

Hi Tobias,

Our current APIs were designed more for one-off calls, such as when you are displaying IntelliPrompt, and not for intense repeated backend resolution. For memory reasons, we don't currently retain the tokens for the snapshot, and therefore the context building logic will lex tokens again on each call. That being said, we do retain lexer contexts at the end of each document line, and the lexer should be able to pick up fairly quickly from anywhere in the document.

I'm wondering if we can avoid the default context building (and lexer) altogether here though since you are purely working on already-constructed parse data structures.  

I did a quick mockup of a context implementation class where you pass it in some info and it will give the bare minimum of what I think the resolver would need. I didn't get to test it here, but perhaps try this kind of concept on your end and see if it helps.

public class QualifiedNameContext : IDotNetContext {

	private TypeDeclaration containingAstTypeDeclaration;

	public QualifiedNameContext(
		IProjectAssembly projectAssembly, 
		IDotNetParseData parseData, 
		ISourceFileLocation location
	) {
		var snapshot = parseData.Snapshot;
		
		// Get the offset right before the source location range end (last character)
		this.ProjectAssembly = projectAssembly;
		this.InitializationSnapshotRange = new TextSnapshotRange(snapshot, location.TextRange);
		this.SnapshotOffset = new TextSnapshotOffset(snapshot, location.TextRange.EndOffset - 1);
		this.TargetSnapshotOffset = new TextSnapshotOffset(snapshot, location.TextRange.EndOffset - 1);

		// Find the AST node that encloses tha offset, which should be an identifier
		var astNode = parseData.Ast.FindDescendantNode(this.SnapshotOffset);
		this.ContainingAstNode = astNode?.Parent;
	}

	public int? ArgumentIndex => null;

	public TextSnapshotOffset? ArgumentListSnapshotOffset => null;

	public TextSnapshotOffset? ArgumentSnapshotOffset => null;

	public IAstNode ContainingAstNode { get; private set; }

	public TypeDeclaration ContainingAstTypeDeclaration {
		get {
			if (containingAstTypeDeclaration == null) {
				var astNode = this.ContainingAstNode;
				while (astNode != null) {
					containingAstTypeDeclaration = astNode as TypeDeclaration;
					if (containingAstTypeDeclaration != null)
						break;

					astNode = astNode.Parent;
				}
			}

			return containingAstTypeDeclaration;
		}
	}

	public TextSnapshotRange? InitializationSnapshotRange { get; private set; }

	public DotNetContextKind Kind => DotNetContextKind.Self;

	public IDotNetContextLocation Location => null;

	public IProjectAssembly ProjectAssembly { get; private set; }

	public TextSnapshotOffset SnapshotOffset { get; private set; }

	public Expression TargetExpression => null;

	public TextSnapshotOffset? TargetSnapshotOffset { get; private set; }

	public IResolverResultSet Resolve() {
		throw new NotImplementedException();
	}

}

Thank you very much. My first tests look very promising.