Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Avoid unnecessary location argument for VB compiling#272

Open
angelowang wants to merge 1 commit intoUiPath:develop from
angelowang:patch-1
Open

Avoid unnecessary location argument for VB compiling #272
angelowang wants to merge 1 commit intoUiPath:develop from
angelowang:patch-1

Conversation

@angelowang
Copy link

@angelowang angelowang commented Jul 2, 2023
edited
Loading

For CompiledExpressionInvoker.ProcessLocationReferences(), the microsoft reference source is not always creating location argument, but only when RequiresCompilation is true, which is for C#.

https://github.com/microsoft/referencesource/blob/master/System.Activities/System/Activities/Expressions/CompiledExpressionInvoker.cs#L245

This helps for performance a lot when there are a lot of expressions to compile.
(21 complex xaml files, the first Execute() drops from 27s to 20s)

For CompiledExpressionInvoker.ProcessLocationReferences, the microsoft reference source is not always create location argument, but only when `RequiresCompilation` is true, which is for C#.
This helps for performance a lot when there are a lot of expressions to compile.
Copy link
Contributor

Reference source is for the .NET Framework. In .NET Framework WF, VB expressions are compiled using a native VB expression compiler at runtime. C# expressions have to be compiled with csc through MsBuild so are compiled at build time. CoreWF uses Roslyn, which is the same for both VB and C#. The whole "requirescompilation" flag then becomes obsolete and is only kept for back-compat. Either both VB and C# should have this change or they both should not.

Copy link
Author

angelowang commented Aug 1, 2023
edited
Loading

Framework: VB - Host Compiler - Runtime compiling - _accessor.CreateLocationArgument(reference, false); not run.

So if I am understanding correctly, in NET6, if they are the same, they both should not call that line? But we still have the check for this:

 if (_textExpression.Language == "VB")
 {
 IList<string> requiredLocationNames = _compiledRoot.GetRequiredLocations(_expressionId);
 CreateRequiredArguments(requiredLocationNames);
 }

Seems already inconsistent.

BTW, CSharpValue code are still similar to .NET framework, and Execute() is using _invoker, instead of some cached _expressionTree.Compile(). That's why I understood they are still different and the requires compilation flag is still somewhat being used.

Our product (using only VB script) removes that and improves performance quite a lot. CoreWF unit tests passing, and our test results also look good :)

Copy link
Collaborator

@aoltean16 aoltean16 left a comment

Choose a reason for hiding this comment

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

For netcore, RequiresCompilation is always set to true. (see ActivityXamlServices.cs line 585)
Considering this, I dont think the PR is relevant anymore.
Thanks

Copy link
Collaborator

aoltean16 commented Jan 30, 2024
edited
Loading

Framework: VB - Host Compiler - Runtime compiling - _accessor.CreateLocationArgument(reference, false); not run.

So if I am understanding correctly, in NET6, if they are the same, they both should not call that line? But we still have the check for this:

 if (_textExpression.Language == "VB")
 {
 IList<string> requiredLocationNames = _compiledRoot.GetRequiredLocations(_expressionId);
 CreateRequiredArguments(requiredLocationNames);
 }

Seems already inconsistent.

BTW, CSharpValue code are still similar to .NET framework, and Execute() is using _invoker, instead of some cached _expressionTree.Compile(). That's why I understood they are still different and the requires compilation flag is still somewhat being used.

Our product (using only VB script) removes that and improves performance quite a lot. CoreWF unit tests passing, and our test results also look good :)

I will have a look at it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@aoltean16 aoltean16 aoltean16 left review comments

@gabriela-lungu-uip gabriela-lungu-uip Awaiting requested review from gabriela-lungu-uip

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

AltStyle によって変換されたページ (->オリジナル) /