Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance is slow for DSL build with CE #12723

Closed
albertwoo opened this issue Feb 13, 2022 · 5 comments
Closed

Performance is slow for DSL build with CE #12723

albertwoo opened this issue Feb 13, 2022 · 5 comments
Labels
Area-ComputationExpressions End-to-end experience for computation expressions (except async and state machine compilation) Feature Improvement

Comments

@albertwoo
Copy link

I am building a DSL for blazor with CE, but we find that when the code line grows to just 300 the performance is going to be noticable. If we got more logic or more lines it is almost no intellicense because it is too slow.

Repro steps

  1. Create an empty .NET 6 fsharp console project
  2. Add package: dotnet add package Fun.Blazor --version 2.0.0-beta008
  3. Copy below code
open Fun.Blazor

let test =
     div {
        div {
            style'' {
                width 100
                height 100
            }
            "test"
        }
        div {
            style'' {
                width 100
                height 100
            }
            "test"
        }
        // repeat for many times
    }

Expected behavior

Should be fast enough for a single file less than 1000 lines

Actual behavior

Slow start from 300 lines of code in a single file

Known workarounds

No

Related information

  • Windows 11
  • VS 2022 17.1.0 preview 4 (Other IDE like vscode and formal VS still have the issue)
@albertwoo albertwoo added the Bug label Feb 13, 2022
@albertwoo
Copy link
Author

albertwoo commented Feb 13, 2022

Related issue: slaveOftime/Fun.Blazor#24

@dsyme
Copy link
Contributor

dsyme commented Feb 16, 2022

TBH this is somewhat expected as things stand - the de-sugaring of CEs can lead to m=plenty of method resolutions and it's not to be taken for granted that it allows very large CE expressions without some penalty in diagnostics and compilation times.

I'd encourage you to consider this when assessing whether the CE technique is suitable for your DSLs. We can aim to continue to improve compilation times for this, and I'd strongly encourage you to do a profiling run - which would probably quickly determine some low hanging fruit on this path. However there should be no real expectation that using CEs on very large inputs will be free of some downsides - it's in their nature.

@albertwoo
Copy link
Author

Maybe we should add this to CE docs to let people know its not suitable for large DSL instead of after we spend many times then find out it is not a suitable way. :(

@albertwoo
Copy link
Author

albertwoo commented Mar 16, 2022

Compared with 16.11.3 and 17.0.6.
16.11.3 is faster and more reliable, in 17.0.6, it is very easy to make the VS crash when the code grows.

The IDE will crash for just 300 lines of CE expression in 17.0.6.

Can we improve CE performance for codes under 500 lines?

@KevinRansom KevinRansom added Impact-Medium (Internal MS Team use only) Describes an issue with moderate impact on existing code. Regression labels Mar 28, 2022
@dsyme dsyme added Area-Compiler-Checking Type checking, attributes and all aspects of logic checking Area-ComputationExpressions End-to-end experience for computation expressions (except async and state machine compilation) and removed Regression Impact-Medium (Internal MS Team use only) Describes an issue with moderate impact on existing code. Area-Compiler-Checking Type checking, attributes and all aspects of logic checking labels Apr 27, 2022
@vzarytovskii vzarytovskii moved this to Not Planned in F# Compiler and Tooling Jun 17, 2022
@vzarytovskii vzarytovskii added this to the Backlog milestone Oct 19, 2022
@T-Gro T-Gro self-assigned this Apr 13, 2023
@T-Gro T-Gro removed this from the Backlog milestone May 4, 2023
@vzarytovskii
Copy link
Member

Let's track this one in #14429, since it has much more info.

@vzarytovskii vzarytovskii closed this as not planned Won't fix, can't repro, duplicate, stale Nov 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-ComputationExpressions End-to-end experience for computation expressions (except async and state machine compilation) Feature Improvement
Projects
Archived in project
Development

No branches or pull requests

5 participants