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

Slow compiler feedback #24

Closed
marcpiechura opened this issue Feb 11, 2022 · 9 comments
Closed

Slow compiler feedback #24

marcpiechura opened this issue Feb 11, 2022 · 9 comments

Comments

@marcpiechura
Copy link

marcpiechura commented Feb 11, 2022

Hey,

I'm trying to build a small web app with your project, but I've noticed that even with only 3 files and ~300LoC Visual Studio as well as VSCode are consuming a lot of resources and the feedback from the compiler is very slow. I'm wondering if that's due to the high usage of CEs? Anyone else seeing such behavior or maybe it's something on my machine?

Also, I tried to switch to the Template.html syntax, but unfortunately it looks like it's not part of the Fun.Blazor.Wasm Nuget package V 2.0.0-beta006, is that expected? Never mind, after looking at the readme again, I saw that I've to use Fun.Blazor.HtmlTemplate ;-)

Thanks in advance and keep up the great work!
Marc

@AngelMunoz
Copy link
Contributor

I think I saw this myself as well with the generated bindings from MudBlazor, I dropped them for a spare project I had and things improved a bit

@albertwoo
Copy link
Contributor

@marcpiechura I noticed this today with my another project(MyLogs). It maybe related to CE. If you keep your single file smaller it may be faster. And you can try to declare some variables for your UI fragment to avoid too much code for a single fragment of UI, which may help.

I will try to figure out why. I am also not sure if inline is the issue.

@albertwoo
Copy link
Contributor

According to the feedback from fsharp repo, CE it is not suitable for large DSL definition which is so sad because I spend a lot of time on this.

But luckly, for default dom attribute I can use a static class (which need to open explicitly) or module to define them to reduce the custom operations. It should work. I hope.

@albertwoo
Copy link
Contributor

Just tried it. Even I moved all the attr operation out of the CE builder, it is still very slow when code grows. It looks like you just cannot have too much stuff put into the CE body.

div {
    // We cannot put too much lines or nest too much lines in a single CE 
}

Sperate them in multiple block can help:

let v1 =
    div {
        ...
    }
div {
    v1
    ....
}

@AngelMunoz
Copy link
Contributor

@albertwoo do you know if templates are affected in the same way?

I guess this issue can be mitigated a little if we push more in the direction of "components" which should be in theory small and extensible via parameters either in function or class mode

And if that really fails I think templates could be the way to continue forward, although I guess typesafety is really important for some people

@albertwoo
Copy link
Contributor

I do think so. According to the issue comment it just the problem of CE:

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.

If you do below things it should be ok for IDE perf, and it will also help comipler to do better inline to reduce allocation and also help on readability:

  1. Keep your single file small
  2. Keep your single CE block small

@albertwoo
Copy link
Contributor

For example in the benchmark I found greate allocation reduce if you help the compiler to do better job on inline:

// Declare a variable help fsharp to have better inline which can save a lot of allocation for delegate
// In this benchmark it can save 40%
counter

@marcpiechura
Copy link
Author

@albertwoo that's unfortunate, I really liked the CE style :(
I switched to the html templates, since I'm fine with having less type safety on the view side and it works pretty well.
Nonetheless, I'm continue to use Fable + React for now, the missing hot reload feature is ruin it for me. I could live with loosing state and doing a full page reload on every change, but the wait time is simply to long compared to the sub second hot reload from Fable + React. (I know that's not the fault or your library).
I'll have to wait until the .Net team finally implements HR for F# projects and then will come back as a happy user ;-)

Thanks,
Marc

@albertwoo
Copy link
Contributor

@marcpiechura fable is great. I use it too.

Some updates before I close this issue:

  1. For CE performace:
    div {
        onclick ignore
        other attrs
        childContent [ ✅
            div { "hi" }
            ...a lot of child items
        ]
    }
    ```

    Or

    ```fsharp
    let fragment1 = ✅
        fragment {
            bunch of items
        }

    div {
        onclick ignore
        other attrs
        div { "hi" }
        fragment1
    }
    ```

    Instead of below:

    ```fsharp
    div {
        onclick ignore
        other attrs
        div { "hi" }
        ...a lot of child items}
    ```

2. Limited hot reload is implemented, you can check: https://funblazor.slaveoftime.fun/hot-reload

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants