-
Notifications
You must be signed in to change notification settings - Fork 7
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
Comments
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 |
@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. |
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. |
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
....
} |
@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 |
I do think so. According to the issue comment it just the problem of CE:
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:
|
For example in the benchmark I found greate allocation reduce if you help the compiler to do better job on inline: Fun.Blazor/Benchmark/BenchmarkV2/BasicBenchmark/CEComponent.fs Lines 61 to 63 in 581c0b7
|
@albertwoo that's unfortunate, I really liked the CE style :( Thanks, |
@marcpiechura fable is great. I use it too. Some updates before I close this issue:
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 |
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
The text was updated successfully, but these errors were encountered: